• Office 365 Portal:

• NAM Portal:

• Atualizar o Chrome para v.51.0.2784 ou superior;
• No ADFS, para quem baixou a segurança, rodar o comando “Set-ADFSProperties –ExtendedProtectionTokenCheck Required”;
• Fazer backup dos user-agents já configurados no ADFS com o commando Get-ADFSProperties;
• No ADFS adicionar o User-Agent para o Chrome rodando o comando “Set-ADFSProperties -WIASupportedUserAgents @(“MSIE 6.0”, “MSIE 7.0”, “MSIE 8.0”, “MSIE 9.0”, “MSIE 10.0”, “Trident/7.0”, “MSIPC”, “Windows Rights Management Client”, “Mozilla/5.0”,”Edge/12”).

1

2

3

4

5

6

7

8

9

10

11

12

Cenários 1, 5 e 9:

Cenário 2:

1. No Exchange Manangement, em cada um dos servidores Hub Transport remover o Receive Connector “Inbound from Office 365”
2. No Exchange Manangement, remover os servidores Hub Transport do Send Connector “Outbound to Office 365” e adicionar os servidores Edge (necessário digitar o nome dos Edges)
3. No Exchange Manangement Shell, configurar o Receive Connector default da Internet em cada servidor Edge usando o comando PowerShell abaixo:

Cenários 3 e 4:

1. No ADSIEdit.msc, no caminho CN=Outbound to Office 365,CN=Connections,CN=Exchange Routing Group (DWBGZMFD01QNBJR),CN=Routing Groups,CN=Exchange Administrative Group (FYDIBOHF23SPDLT),CN=Administrative Groups,CN=<Org>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<domain> alterar o atributo msExchSmtpSendFlags de 64 para 131136 (ver mais infos sobre esse atributo ao final do post).
2. Force a execução do EdgeSync via PowerShell usando Start-EdgeSubscription
3. No Exchange Manangement, em cada um dos servidores Hub Transport remover o Receive Connector “Inbound from Office 365”
4. No Exchange Manangement, remover os servidores Hub Transport do Send Connector “Outbound to Office 365” e adicionar os servidores Edge (necessário digitar o nome dos Edges)
5. No Exchange Manangement Shell, configurar o Receive Connector default da Internet em cada servidorEdge usando o comando PowerShell abaixo:

Cenários 6, 7, 8, 10, 11 e 12:

1. No Exchange Manangement Shell, configurar o Receive Connector default da Internet em cada servidor Edge usando o comando PowerShell abaixo:

Antes de começar faça a configuração das placas de rede e endereços IP, DNS, etc.

1) Adicione o sufixo ao nome dos Servidores Edge. Ex.: edge01.hunecke.net e reinicie o computador.

2)  Faça a instalação dos pré-requisitos via UI ou através do comando PowerShell abaixo:

Add-WindowsFeature ADLDS,Telnet-Client

3) Faça a instalação dos servidores Edge via UI ou através do comando PowerShell abaixo:

Setup.exe /Mode:Install /Roles:EdgeTransport /IAcceptExchangeServerLicenseTerms

4) O serviço Microsoft Exchange Health Manager não deve iniciar automaticamente, por um erro no código do setup do Exchange, conforme artigo: http://support.microsoft.com/en-us/kb/3017629. Abra o regedit.exe, navegue até HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\MSExchangeHM, abra a entrada DependOnService e remova o valor MSExchangeADTopology. Reinicie o servidor.

5) Copie o arquivo *.pfx com o certificado público para os servidores Edge. Importe o certificado via MMC e Instale o certificado nos servidores Edge através do comando PowerShell abaixo:

Enable-ExchangeCertificate -Thumbprint 9245E167E25223D85BF799982AE1A4848D6DA04A -Services:smtp

Na pergunta sobre sobrescrever ou não o cerificado default do serviço SMTP é obrigátório responder “Não”.  Em breve, farei um post específico sobre este assunto e coloco no link.

OBS1.: Se vc estiver utilizando os servidores Edge para conexão com Office 365, o certificado deve ser o mesmo utilizado nos servidores Mailbox e CAS.

OBS2.: Qualquer alteração feita nos certificados requer que um novo Edge subscription seja refeito.

6) Nos servidores Edge, crie uma Edge Subscription para cada servidor, através do comando PowerShell abaixo (pressione Y para confirmar):

New-EdgeSubscription –FileName “c:\MyEdgeSubscription-Edge01.xml”

New-EdgeSubscription –FileName “c:\MyEdgeSubscription-Edge02.xml”

7) Confirme que os todos os servidores Mailbox conseguem resolver o FQDN dos servidores Edge.

8) Crie uma regra de firewall em todos servidores Mailbox liberando a porta 50636 para conexão com os servidores Edge, através dos comandos PowerShell abaixo:

Invoke-Command –ComputerName Mailbox01.hunecke.net {New-NetFirewallRule -DisplayName "Allow outbound TCP Port 50636 - Edge Service" -Direction outbound –LocalPort 50636 -Protocol TCP -Action Allow}

Invoke-Command –ComputerName Mailbox02.hunecke.net {New-NetFirewallRule -DisplayName "Allow outbound TCP Port 50636 - Edge Service" -Direction outbound –LocalPort 50636 -Protocol TCP -Action Allow}

9) Copie os arquivos gerado no passo 6 e configure a replicação do Edge para apenas um servidor Mailbox através do comando PowerShell abaixo:

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path “c:\MyEdgeSubscription-Edge01.xml” -Encoding Byte -ReadCount 0)) -Site “Default-First-Site-Name”

New-EdgeSubscription -FileData ([byte[]]$(Get-Content -Path “c:\MyEdgeSubscription-Edge01.xml” -Encoding Byte -ReadCount 0)) -Site “Default-First-Site-Name”

10) Inicie a replicação da configuração entre os servidores Edge e os servidores Mailbox (executando em qualquer servidor Mailbox) através do comando PowerShell abaixo:

Start-EdgeSynchronization

10) Nos Servidores Edge, instale o Product Key via UI ou através do comando PowerShell abaixo:

Set-ExchangeServer -Identity edgeserver -ProductKey aaaaa-aaaaa-aaaaa-aaaaa-aaaaa

11) Caso vocês esteja utilizando os Servidores Edge para conectar com o Office 365, após a execução do Hybrid Configuration Wizard (HCW) é necessário ajustar o Receive-Connector com o comando PowerShell abaixo:

Set-ReceiveConnector -Identity <Name of Internet-facing connector> -TlsDomainCapabilities mail.protection.outlook.com:AcceptOorgProtocol -Fqdn

-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-

Atualizado em 13/01/2016 – Inclusão do item 5 – Instalação dos certificados

Atualizado em 14/01/2016 – inclusão da nota sobre não reescrever o certificado default do SMTP e inclusão do item 11 – Ajustes no receive-connector após a execução do HCW (Hybrid Configuration Wizard).  * Contribuição do PFE Vanderson Vicentin.

1) Erro de sync de algum objeto com valor inválido em algum atributo.

Algumas aplicações (ex. SAP e Squid) precisam alterar o UPN do seu usuário de serviço para um formato não aceito pelo Office 365. Nos casos que já peguei o formato do UPN é algo como: “host/username@domínio.com.br”. Como este formato não é aceito no Azure AD a cada sincronização um novo erro é gerado, como abaixo:

Como este tipo de objeto não precisa ser sincronizado com Office 365, a recomendação é criar um filtro de objeto no Azure AD Connect.

No DirSync era fácil de fazer, bastava criar um novo filtro no Management Agent (MA) na opção “Configure Connector Filter”, porém essa opção não está mais disponível no MA da Azure AD Connect. Portanto para criar um filtro de um objeto no Azure AD Connect use os passos abaixo:

a) Abra o Synchonization Rules Editor a partir do botão Windows

b) Clique em Add New Rule e crie um nova regra, conforme abaixo:

Obs.: O atributo cloudFiltered deve ser definido igual a True

Ao final clique no botão Add para adicionar a o filtro.

Voltando a Synchronization Service Manager rode um Full Import & Full Synchronization do MA que foi modificado.

Esse fitro faz com o que o usuário cujo Display name é igual a “SquidGuard” não seja sincronizado com Office 365 e automaticamente não dê mais erro na sincronização.

2) Warning export-change-not-reimported

Durante a sincronização Delta Import do Azure AD aparece a mensagem (warnings) abaixo para alguns grupos:

Verificando os grupos percebi que todos estes grupos tinham como membros alguma conta de computador que é Domain Controller (HUNECKE-AD01 ou HUNECKE-AD02), e como as contas de DCs não são sincrinizados com Office 365, é foi necessário criar um filtro para excluir essas contas de computador, conforme abaixo:

a) Abra o Synchonization Rules Editor a partir do botão Windows

b) Clique em Add New Rule e crie uma nova regra, conforme abaixo:

Se você criar condições no mesmo grupo, todas as regras deverão ser Verdadeiras
Para excluir 2 ou mais contas de computador, é necessário criar um grupo para cada conta de computador.

Obs.: O atributo cloudFiltered deve ser definido igual a True

3) Required attribute cloudanchor is missing

Durante a sincronização Export do Azure AD aparece a mensagem abaixo para algum usuário:

Abrindo os detalhes do erro chegamos à mensagem:

Essa mensagem geralmente aparece para usuários recém excluídos no Office 365 Portal ou PowerShell e no Office 365 o usuário ainda está na lixeira Recycle Bin). Para resolver exclua o usuário e depois exclua da lixeira usando os seguintes comandos PowerShell:

Remove-MsolUser -UserPrincipalName user@yourdomain.com
Remove-MsolUser -UserPrincipalName user@yourdomain.com –RemoveFromRecycleBin

Após a nova sincronização a conta do usuário será criada novamente no Office 365.

Rode um Full Sync através do comando: C:\Program Files\Microsoft Azure AD Sync\Bin\DirectorySyncClientCmd.exe initial

4) Stopped-server-down

Durante a sincronização Export do Azure AD aparece a mensagem abaixo:

Stopped-server-down message

Um das causas deste erro pode ser a restrição de execução de usuário em massa, ou seja, o comando Enable-ADSyncExportDeletionThreshold. foi executado.

Para resolver, é necessário desativar essa prevenção usando o comando: Disable-ADSyncExportDeletionThreshold,e rodar novamente o Export do MA do Azure AD.

Depois destes ajustes, com filtros por usuário e por conta de computador, o Azure AD Connect está sincronizado 100%, sem qualquer erro ou mesmo warning, como abaixo:

Source: https://msdn.microsoft.com/en-us/library/azure/dn801051.aspx

O principal desafio destas soluções de MFA é tratar as conexões do Outlook Client e da Lync client com o Office 365, pois estas aplicações não utilizar SAML padrão para fazer a autenticação, logo, quando habilitado MFA, os usuários dessas aplicações não conseguem se autenticar e ficam repetidamente solicitando as credencias do usuário.

Algumas alternativas:

1) Habilitar MFA apenas para acesso externo e liberar apenas o OWA (Outlook Web App), mas limitaria significativamente a experiência dos usuários, logo não atende.

2) Habilitar MFA apenas para acesso externo e forçar que o acesso seja sempre feito via VPN, na maioria dos casos também não atende, pois perde-se o conceito de “nuvem” (acesso de qualquer lugar, qualquer devices).

Mesmo que qualquer uma destas soluções acima atendesse a necessidade de negócio, tem um problema adicional. O Outlook client dentro da rede corporativa tenta fazer a autenticação externamente (passando pelo Web Application Proxy também conhecido como ADFS Proxy).

Para resolver isso, é necessário criar uma condição adicional de uso do MFA.

Quando o MFA é ativado para acesso externo uma regra adicional de autenticação é criada, que valida se a solicitação de autenticação está vindo da rede corporativa ou da rede externa. Se a condição for verdadeira aplica a regra, ou seja, exige MFA.

Intranet = solicitação direto no ADFS

Extranet = solicitação encaminhada via Web Proxy Application

c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");

Em resumo: essa regra foça autenticação MFA para todas as aplicações (Portal, Outlook, Lync) quando vindo de fora da rede corporativa, o que faz o Outlook e Lync pararem de funcionar externamente o Outlook internamente.

Para solicitar isso, é necessário adicionar uma nova condição na regra acima, controlando qual tipo de cliente que está requisitando a autenticação. Se for requisição web, solicita MFA, se for aplicação Outlook ou Lync não pede MFA.

A condição mais fácil de ser aplicada é a que valida o valor se o valor “x-ms-endpoint-absolute-path” recebida na requisição de autenticação é igual a “/adfs/ls”, isso quer dizer que requisição é vinda de um browser, como por exemplo, acesso ao portal do Office 365 ou mesmo OWA.

Com isso a regra ficaria:

c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "(/adfs/ls)"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn"); c:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");

Explicação dada, vamos à prática, como implementar isso no servidor ADFS:

O ajuste necessário para fazer o “by-pass” do Outlook tanto quando é acessado de dentro e de fora segue abaixo:

1) Adicionar as a Claim rules para Active Directory Provider, conforme step2 do artigo https://technet.microsoft.com/en-us/library/hh526961(v=ws.10).aspx

Além das 5 rules regras já documentadas, incluir também a http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod

2) Habilitar o MFA para Extranet no console do ADFS, selecionando apenas Extranet;

3) Fazer backup do configuração das Relying Party Trust, com o comando: Get-AdfsRelyingPartyTrust (guardar o resultado de saída para uma eventual necessidade de restore);

4) Rodar o seguinte comando PowerShell para reconfigurar o Relying Party Trust forçando autenticação MFA apenas para acesso via browser e fazendo by-pass da autenticação quando acesso for por Outlook/Lync, etc....

$rp = Get-AdfsRelyingPartyTrust -Name "Microsoft Office 365 Identity Platform"

$GroupMfaClaimTriggerRule = 'c:[Type == "http://schemas.microsoft.com/2012/01/requestcontext/claims/x-ms-endpoint-absolute-path", Value =~ "(/adfs/ls)"] && c1:[Type == "http://schemas.microsoft.com/ws/2012/01/insidecorporatenetwork", Value == "false"] => issue(Type = "http://schemas.microsoft.com/ws/2008/06/identity/claims/authenticationmethod", Value = "http://schemas.microsoft.com/claims/multipleauthn");'

Set-AdfsRelyingPartyTrust -TargetRelyingParty $rp -AdditionalAuthenticationRules $GroupMfaClaimTriggerRule

5) Fazer os testes.

(nos próximos dias colocaria alguns Print Screen de referência)

Atualmente as principais entidades certificadoras públicas estão começando a solicitar certificados com Algoritmo de Assinatura (Signature algorithm) SHA-2, conforme abaixo:

Signature Algorithm:
    Algorithm ObjectId: 1.2.840.113549.1.1.11 sha256RSA
    Algorithm Parameters:
    05 00

Hoje em dia, os assistentes de criação de request do Exchange, IIS, Certificate Authoriry (via console ou mesmo, via WebSite) ainda não fazem requests com SHA-2, apenas com SHA-1.

Para gerar os request com SHA-2 não é possível utilizar o Wizard o Lync Server e sim, é necessário utilizar uma ferramenta adicional, no meu caso escolhi utilizar OpenSSL que está disponível para download em: http://slproweb.com/products/Win32OpenSSL.html (Escolha a versão 64 bits).

Passo a passo:

1) Em qualquer servidor (preferencialmente em algum servidor Edge), baixe a ferramenta OpenSSL e instale. O caminho default é c:\OpenSSL-Win64\bin\

2) Para o certificado interno do Edge - Crie um arquivo na pasta onde o OpenSSL foi instalado com o nome LyncInternalConfig.cnf com o seguinte conteúdo:

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[ req_distinguished_name ]
C = BR
ST = RS
L = Porto Alegre
O = Hunecke Company
OU = TI
CN = rtcedge.hunecke.net
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = critical, CA:FALSE
keyUsage = critical, digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectKeyIdentifier=hash
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = rtcedge.hunecke.net
DNS.2 = edge01.hunecke.net
DNS.3 = edge02.hunecke.net

3) Para o certificado externo do Edge - Crie um arquivo na pasta onde o OpenSSL foi instalado com o nome LyncExternalConfig.cnf com o seguinte conteúdo:

[ req ]
distinguished_name = req_distinguished_name
req_extensions = v3_req
prompt = no
[ req_distinguished_name ]
C = BR
ST = RS
L = Porto Alegre
O = Hunecke Company
OU = TI
CN = sip.hunecke.com.br
[ v3_req ]
# Extensions to add to a certificate request
basicConstraints = critical, CA:FALSE
keyUsage = critical, digitalSignature, nonRepudiation, keyEncipherment, dataEncipherment
extendedKeyUsage = serverAuth
subjectKeyIdentifier=hash
subjectAltName = @alt_names
[ alt_names ]
DNS.1 = sip.hunecke.com.br
DNS.2 = webcon.hunecke.com.br
DNS.3 = webext.hunecke.com.br
DNS.4 = webdirext.hunecke.com.br
DNS.5 = meet.hunecke.com.br
DNS.6 = dialin.hunecke.com.br
DNS.7 = officewebapps01.hunecke.com.br
DNS.8 = lyncdiscover.hunecke.com.br

4) Para o certificado interno do Edge – Rode o seguinte comando no Command Prompt:

cd c:\OpenSSL-Win64\bin

openssl req -nodes -sha256 -newkey rsa:2048 -keyout C:\OpenSSL-Win64\PrivateKey.key -out C:\OpenSSL-win64\bin\ LyncInternalConfig.req -config C:\OpenSSL-Win64\bin\LyncInternalConfig.cnf

5) Para o certificado externo do Edge – Rode o seguinte comando no Command Prompt:

cd c:\OpenSSL-Win64\bin

openssl req -nodes -sha256 -newkey rsa:2048 -keyout C:\OpenSSL-Win64\PrivateKey.key -out C:\OpenSSL-win64\bin\ LyncExternalConfig.req -config C:\OpenSSL-Win64\bin\LyncExternalConfig.cnf

6) Os requests foram gerados na pasta C:\OpenSSL-win64\bin\ com os nomes: LyncInternalConfig.cer e LyncExternalConfig.cer. Encaminhe para a entidade certificadora pública.

Em breve, mais detalhes sobre o request SHA-2.

Neste cenário o CMS está no pool Lyncsdt01.contoso.com e os usuários estão divididos entre os 2 Pools (Lyncsdt01.contoso.com  e Lyncsdt02.contoso.com).

O script migra o CMS para o pool Lyncsdt02.contoso.com  e ativa todos os usuários do pool Lyncsdt01.contoso.com  no pool Lyncsdt02.contoso.com..

Cenário onde a parade do pool Lyncsdt01.contoso.com  é programada.

Start-CsWindowsService -ComputerName LYNCSTD01.contoso.com
Start-CsWindowsService -ComputerName LYNCSTD02.contoso.com
Get-CsBackupServiceStatus -PoolFqdn lyncstd01.contoso.com
Get-CsBackupServiceStatus -PoolFqdn lyncstd02.contoso.com
Invoke-CsManagementServerFailover -BackupSqlInstanceName RTC -BackupSqlServerFqdn lyncSTD02.contoso.com -Force:$False -Confirm:$False
Invoke-CsPoolFailOver -PoolFqdn lyncstd01.contoso.com -DisasterMode:$False -Confirm:$False

O script abaixo volta o CMS para o pool Lyncsdt01.contoso.com e reativa os usuários no pool Lyncsdt01.contoso.com.

Invoke-CsPoolFailBack -PoolFqdn lyncstd01.contoso.com -DisasterMode:$False -Confirm:$False
Invoke-CsManagementServerFailover -BackupSqlInstanceName RTC -BackupSqlServerFqdn lyncSTD01.contoso.com -Force:$False -Confirm:$False
Get-CsBackupServiceStatus -PoolFqdn lyncstd01.contoso.com
Start-CsWindowsService -ComputerName LYNCSTD01.contoso.com
Start-CsWindowsService -ComputerName LYNCSTD02.contoso.com

Cenário onde o pool Lyncsdt01.contoso.com ficou indisponível (não programado).

OBS.: a única diferença do script acima é que os parâmetros Force (comando Invoke-CsManagementServerFailover ) e DisasterMode (comando Invoke-CsPoolFailOver) devem ser configurados como True, pois o Lyncsdt01.contoso.com  não está disponível. No script de failback (segunda parte) não há diferença, pois considera-se que na hora de fazer o failback ambos os pools estão disponíveis.

Start-CsWindowsService -ComputerName LYNCSTD01.contoso.com
Start-CsWindowsService -ComputerName LYNCSTD02.contoso.com
Get-CsBackupServiceStatus -PoolFqdn lyncstd01.contoso.com
Get-CsBackupServiceStatus -PoolFqdn lyncstd02.contoso.com
Invoke-CsManagementServerFailover -BackupSqlInstanceName RTC -BackupSqlServerFqdn lyncSTD02.contoso.com -Force:$True -Confirm:$False
Invoke-CsPoolFailOver -PoolFqdn lyncstd01.contoso.com -DisasterMode:$True-Confirm:$False

Invoke-CsPoolFailBack -PoolFqdn lyncstd01.contoso.com -DisasterMode:$False -Confirm:$False
Invoke-CsManagementServerFailover -BackupSqlInstanceName RTC -BackupSqlServerFqdn lyncSTD01.contoso.com -Force:$False -Confirm:$False
Get-CsBackupServiceStatus -PoolFqdn lyncstd01.contoso.com
Start-CsWindowsService -ComputerName LYNCSTD01.contoso.com
Start-CsWindowsService -ComputerName LYNCSTD02.contoso.com

Atualmente, não existem cmdlets que mostram detalhes dos Routing Groups, nem mesmo listam eles. Pois isso, consolidei o conteúdo de várias fontes e gerei um script PowerShell que conecta no SQL Server e apresenta a lista dos Routing Groups, nome do servidor Front End e usuários associados ao Routing Group.

Para rodar o script abaixo, basta modificar a primeira linha do script ($SqlServer = ), usando o format “FrondEndServer\SQLInstance”.

#***** Inicio do script *******

$SqlServer = "lyncent01\rtclocal"
$SqlDatabase = "rtc"
    
$SqlQuery = "Select RoutingGroupAssignment.RoutingGroupName, FrontEnd.Fqdn, Resource.UserAtHost from [rtc].[dbo].ResourceDirectory
INNER JOIN [rtc].[dbo].Resource
ON ResourceDirectory.ResourceId=Resource.ResourceId
INNER JOIN [rtc].[dbo].RoutingGroupAssignment
ON ResourceDirectory.RoutingGroupId=RoutingGroupAssignment.RoutingGroupId
INNER JOIN [rtc].[dbo].FrontEnd
ON RoutingGroupAssignment.FrontEndId=FrontEnd.FrontEndId
ORDER BY [rtc].[dbo].RoutingGroupAssignment.RoutingGroupId"

$SqlConnection = New-Object System.Data.SqlClient.SqlConnection
$SqlConnection.ConnectionString = "Server = $SqlServer; Database =
$SqlDatabase; Integrated Security = True"
$SqlCmd = New-Object System.Data.SqlClient.SqlCommand
$SqlCmd.CommandText = $SqlQuery
$SqlCmd.Connection = $SqlConnection
$SqlAdapter = New-Object System.Data.SqlClient.SqlDataAdapter
$SqlAdapter.SelectCommand = $SqlCmd
$DataSet = New-Object System.Data.DataSet
$SqlAdapter.Fill($DataSet)
$SqlConnection.Close()
Clear
#output the data
$DataSet.Tables[0]

#***** Final do script *******

O resultado esperado é algo como:

RoutingGroupName                      Fqdn                    UserAtHost
----------------                      ----                    ----------
fd09e63c-8643-5799-bd0c-9bd54af88858  LYNCENT03.contoso.com   RtcApplication-3dd1..
fd09e63c-8643-5799-bd0c-9bd54af88858  LYNCENT03.contoso.com   GC-1-PersistentChat..
fd09e63c-8643-5799-bd0c-9bd54af88858  LYNCENT03.contoso.com   Yan@contoso.com
cc509a2a-6ebc-50e2-9ee1-140cf72076bb  LYNCENT01.contoso.com   Jeff@contoso.com
406f2b07-bb5b-563c-a588-ae387660b98b  LYNCENT01.contoso.com   Jim@contoso.com
a83fca89-c2a8-56fb-9a38-9f8ec8e2a983  LYNCENT03.contoso.com   Jon@contoso.com
255e1329-a560-52b2-98d3-67c49ec81d38  LYNCENT02.contoso.com   Mike@contoso.com
94a40ddd-e63d-50b7-a8b8-b8733245053b  LYNCENT02.contoso.com   Nate@contoso.com
5ea41329-5003-560a-bd08-90f2cfa2560e  LYNCENT02.contoso.com   Toby@contoso.com

Ref.: http://blogs.technet.com/b/rischwen/rss.aspx