Office 365 Hybrid Configuration Wizard for Exchange 2010 free/busy bug

Recently we used the new Office 365 Hybrid Configuration Wizard for Exchange 2010.

The Office 365 Hybrid Configuration wizard has been updated to support Exchange 2010. This new wizard comes with the following advantages:

  • An updated user experience that simplifies the hybrid configuration process
  • The error handling experience allows for simple remediation of issues, meaning you can actually read and understand the error
  • Fixes for HCW can happen quickly and are no longer tied to the on-premises product release cycle
  • Inefficient code that caused the HCW to take hours to run has been completely reworked and now you should be in and out in minutes

The on-premises Exchange 2010 environment was updated to the latest SP and CU and had one multi-role hybrid server. For the new Office 365 HCW please read this article published by the Exchange product team.

The HCW ran smoothly without big issues and completed succesfully. However when testing the created functionality we noticed free/busy didn’t work from on-prem users to cloud users. The free/busy worked like a charm vice-versa.

When troubleshooting further we ran the following two PowerShell cmd-lets to test the created OrganizationFederation on the on-premises Exchange Organization.

Get-FederationInformation -DomainName contoso.mail.onmicrosoft.com

Test-OrganizationRelationship -Identity “On-premises to O365 – 9a4a2b73-ebb9-4925-91ec-3b4dae60
6805” -UserIdentity clouduser@contoso.com 

Both cmd-lets resulted in this generic error message:

WARNING: An unexpected error has occurred and a Watson dump is being generated:

After running the Test-OrganizationRelationship cmd-let with the -Verbose parameter we noticed all steps and iterations done and exactly where the cmd-let failed. The cmd-let failed on the EWS call to our tenant at this step:

Test-OrganizationRelationship : Calling the Microsoft Exchange Autodiscover service for the remote federation information.

Further down the pipeline we noticed this explicit error message which contained valuable troubleshooting information.

Test-OrganizationRelationship : The Microsoft Exchange Autodiscover service failed to be called at ‘https://autodiscover.outlook.com/autodiscover/autodiscover.svc’ because the following error occurred:
Exception:
Microsoft.Exchange.SoapWebClient.GetFederationInformationException: Discovery for domain contoso.mail.onmicrosoft.com failed. —>
System.Net.WebException: Unable to connect to the remote server —> System.Net.Sockets.SocketException: No connection
could be made because the target machine actively refused it 132.245.226.24:443
at System.Net.Sockets.Socket.DoConnect(EndPoint endPointSnapshot, SocketAddress socketAddress)
at System.Net.ServicePoint.ConnectSocketInternal(Boolean connectFailure, Socket s4, Socket s6, Socket& socket,
IPAddress& address, ConnectSocketState state, IAsyncResult asyncResult, Int32 timeout, Exception& exception)
— End of inner exception stack trace —

After comparing the current OrganizationRelationship (see image below)  with other clients hybrid configurations we noticed a difference on the TargetAutodiscoverEpr memberobject of the OrganizationRelationship object.

26-4-2016 10-48-56.png

At the OrganizationRelationship which was created by the new Office 365 Hybrid Configuration Wizard for Exchange 2010 the TargetAutodiscoverEpr was configured at the https://autodiscover.outlook.com/autodiscover/autodiscover.svc/WSSecurity namespace. At the other clients environment we used the built-in HCW from the Exchange 2010 EMC. And the namespace of the TargetAutodiscoverEpr was different. It had https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity configured and worked like a charm.

Now when we found the dissimilarity in both configurations we contacted Microsoft. We told Microsoft Suppoort that we used the brand-new Office 365 Hybrid Configuration Wizard for Exchange 2010 and showed them the other clients environment. Microsoft proposed to change the namespace on the environment to https://autodiscover-s.outlook.com/autodiscover/autodiscover.svc/WSSecurity and test free/busy calls. After changing the value to the correct namespace the free/busy availability information worked!

Microsoft is further investigating this behaviour but to me it looks a lot like a bug in the new Office 365 HCW for Exchange 2010 environments. So please be aware for this behaviour when running the newly published HCW on Exchange 2010 environments…

Cheers!

Using the SimpleDisplayName attribute for Exchange and Exchange Online in Office 365 with PowerShell

So I came across a scenario where a organization doesn’t use the DisplayName field for external mailflow and has this disabled on their Remote Domain. In this scenario messages will use the SMTP address.

This setting is enabled by default and Exchange Server will use the DisplayName field for external mailflow. Now imagine the scenario you want your users to use a different and somewhat more catchy name for external parties and suppliers. A nice additional attribute can be used for this, which is the SimpleDisplayName attribute. By populating this object with for instance “John Doe – Microsoft Corporation” you will use this information for external parties, and keep using the already in-place DisplayName attribute for internal mailfow and these changes wont affect your Global Address List.

Now to enable Exchange Server, or Exchange Online to use start using the SimpleDisplayName object this needs to be enabled on your Remote Domain. This can be done via a simple PowerShell one-liner.

Set-RemoteDomain -Identity Default -UseSimpleDisplayName $true

Now once this is done Exchange will stop using the populated DisplayName field, and it will use the empty SimpleDisplayName field on userobjects. While being empty and not populated Exchange will use the SMTP Address for external mailflow, so next step will be populating all the empty fields  with the new desired values.

To accomplish this I use this handy PowerShell script which uses the FirstName and LastName attribute and adds a catchy company name behind it.

$users = Get-User -ResultSize Unlimited
foreach ($user in $users) {

$name=$user.DisplayName

$SDN=[string]::Concat($user.FirstName.Trim(), ” “, $user.LastName.Trim(), ” – Microsoft Corporation”)

Set-User $user.Identity -SimpleDisplayName $SDN

}

Intune device enrollment AD FS sign-in error “An error occurred. Contact your administrator for more information.”

Recently a client of mine added Windows Intune to their existing Office 365 subscription. The enablement of Intune requires users to install the Company Portal App on their mobile device which enrolls their device to your Office 365 organization.

In the process of enrolling a device it asks to login to Office 365. When a user tries to login with a federated Identity useraccount the login session will be redirected to your local AD FS sign-in page. However, when this is done from a mobile device it throws an error.

“An error occurred. Contact your administrator for more information.”

4-2-2016 14-17-03

Now once you have a look on the AD FS Admin eventviewer logging which can be found under the Applications and Services tree in the eventviewer MMC snap-in.

There you will find the error listed below:

Encountered error during federation passive request.

Additional Data

Protocol Name:
wsfed

Relying Party:
urn:federation:MicrosoftOnline

Exception details:
Microsoft.IdentityServer.Service.Policy.PolicyServer.Engine.InvalidAuthenticationTypePolicyException: MSIS7102: Requested Authentication Method is not supported on the STS.
at Microsoft.IdentityServer.Web.Authentication.GlobalAuthenticationPolicyEvaluator.EvaluatePolicy(IList`1 mappedRequestedAuthMethods, AccessLocation location, ProtocolContext context, HashSet`1 authMethodsInToken, Boolean& validAuthMethodsInToken)
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.RetrieveFirstStageAuthenticationDomain(Boolean& validAuthMethodsInToken)
at Microsoft.IdentityServer.Web.Authentication.AuthenticationPolicyEvaluator.EvaluatePolicy(Boolean& isLastStage, AuthenticationStage& currentStage, Boolean& strongAuthRequried)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthMethodsFromAuthPolicyRules(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.GetAuthenticationMethods(PassiveProtocolHandler protocolHandler, ProtocolContext protocolContext)
at Microsoft.IdentityServer.Web.PassiveProtocolListener.OnGetContext(WrappedHttpListenerContext context)

Solution:

  1. Logon to AD FS server(s).
  2. Open the AD FS Management Console
  3. On the right hand side right click on the Authentication Policies folder
  4. Choose “Edit Global Primary Authentication…”
  5. In this menu you should check (enable) Forms Authentication on both Intranet and Extranet.

 

After enabling forms authentication on both sides the AD FS requests sent from mobile devices will be succesfully authenticated by the AD FS secure token service.

Add Office 365: Exchange Online e-mail address on every mailbox with PowerShell

When carrying out hybrid Exchange deployments to Office 365: Exchange Online one of the challenges I commonly face is the disablement of the e-mail address policy on stacks of mailboxes. To handle mailflow in a hybrid scenario every mailbox needs an e-mail routing address matching the tenant e-mail domainname (contoso.mail.onmicrosoft.com). Now this requirement is covered by running the Hybrid Configuration Wizard in stage 8: configuring mailflow. This phase simply adds the new e-mail routing address to the “Default Policy”.

This new configuration automatically adds the new e-mail address on every mailbox which has the e-mail address policy enabled on it. Now this is where the challenge appears. What to do when a lot of mailboxes within your Exchange organisation do not have the e-mail address policy enabled?

The easiest fix is enabling the e-mail address policy on every mailbox with a simple one-liner of PowerShell right? Well in a lot cases this solution doesn’t suffice because this would mess up naming conventions. A lot of IT departments knowingly disabled the policy on mailboxes over the years to configure the desired e-mail address by hand for their end-users.

To automatically configure or add the new e-mail address on every mailbox without enabling the e-mail address policy I use this great PowerShell script.

<#
.SYNOPSIS
The Add-O365MailAddress script is used to add your Office 365 e-mail address on every mailbox within your Exchange Organisation.

.DESCRIPTION
The Add-O365MailAddress script is used to add a new Office 365 e-mail address on every mailboxes where it is currently not present.

Make sure script execution is set to unrestricted by running “Set-ExecutionPolicy -ExecutionPolicy unrestricted -Force”

Please note that this script is only tested on Windows Server 2008 R2 and higher servers which have the Exchange Management Shell installed.
#>

$mailbox = Get-Mailbox -ResultSize Unlimited -Filter {EmailAddresses -notlike “*@contoso.mail.onmicrosoft.com*”}
foreach ($user in $mailbox) {

$alias=$user.alias

$email=$alias + “@contoso.mail.onmicrosoft.com”

Set-mailbox $user.Identity -EmailAddresses @{add=$email}
}

Export-Csv -Path c:\temp\mailboxes_output.csv

 

DOWNLOAD HERE

The script iterates trough every mailbox in the Exchange Organisation. Every mailbox which does not have a present Office 365 routing address (contoso.mail.onmicrosoft) is put in the pipeline. Next the script will add the new e-mail address on every selected mailbox which is required for for Office 365 hybrid mailflow.

Remove SMTP aliases and e-mail addresses from all mailboxes on Exchange 2007 with PowerShell

When migrating your on-premises Exchange organization to Office 365: Exchange Online a common challenge is removing old and unused SMTP aliasses or e-mail addresses.

It’s rather easy to create new SMTP addresses to a mailbox or recipient in Exchange via an e-mail address policy. However it can be a real pain in the ass removing specific e-mail addresses and namespaces on mailboxes. Since it is not allowed to have unaccepted domain SMTP addresses on a mailbox prior migrating to Exchange Online this is a core requirement and activity to be carried out.

Another challenge is the incapability of the version of the Exchange 2007 Management Shell to run this special hash table syntax which is only supported for Exchange 2010 SP1 or higher. Most of the PowerShell scripts I looked for use this particular syntax, making them useless for Exchange 2007.

For this example I used the domainname contoso.com to be removed from all User and Shared Mailboxes within the Exchange organization.

$alias = Get-Mailbox -ResultSize Unlimited | Where {$_.EmailAddresses -like ‘*contoso.com’}
$alias | Select-Object -property SamAccountName,UserPrincipalName,EmailAddresses,PrimarySmtpAddress | Export-Csv “mailboxes_with_contoso.com.csv”

foreach($L in $alias)
{
$x = $L
$y = $x.EmailAddresses | where{$_.AddressString -like ‘*@contoso.com’}
$z = $y.SmtpAddress
$T = $x.UserPrincipalName
Write-host $x.EmailAddresses
Write-host “*****”
if($z){
$x.EmailAddresses -= $z
$x | Set-mailbox
Write-Host “$z is removed”
Write-Host “Check”
Write-host $x.EmailAddresses
}else{
Write-Host “$T does not have a contoso.com SMTP Address.”
}
Write-host “####################################################”
#Return
}

This script will iterate through each mailbox, and look for an address containing the @contoso.com namespace. Any matches are removed. To use this code, just replace contoso.com with the e-mail domain you want to remove. The script also contains some logging for you to digg to if you’re up for it.

In my scenario this was required for removing the unvalidated Office 365 domains prior to migrating mailboxes. When you have succesfully executed the script don’t forget to kick off a Full DirSync to make sure the changes are synced to Windows Azure Active Directory.

Best of luck to you all with carrying out succesfull Office 365 deployments. Before I publish the post, I have thank to my colleague and teammate Dev Chaudhari for working on the scripting!

Hybrid Configuration Wizard : Exception=The remote server returned an error: (407) Proxy Authentication Required

A while ago we were facing some issues when running the Exchange 2013 Hybrid Configuration Wizard (HCW) for Exchange Online. As it is recommended to bypass proxy servers for most of the Office 365 services. This is absolutely necessary for Exchange Online in a hybrid scenario.

When running the  HCW it actually runs a large series of PowerShell commandlets which you develop by configuring the New-HybridConfiguration cmd-let with all the required parameters. Once configured it actually goes through these eleven phases:

  1. Creation of Hybrid Configuration Object (New-HybridConfiguration)
  2. Check Tenant Prerequisites
  3. Upgrading Hybrid Configuration from Exchange 2013
  4. Check Prerequisites
  5. Configure Recipient Settings
  6. Creating Organization Relationship
  7. Configure Free/Busy Settings
  8. Configure Mail Flow
  9. Configure MRS Proxy Settings
  10. Configure IntraOrganization Connector
  11. Configure OAuth

Now when we were facing this issue we ended up getting stuck at phase 6 which is configuring the Organization Relationship. One which is rather complex. The Hybrid Configuration Wizard threw this error:

ERROR: System.Management.Automation.RemoteException: Federation information could not be received from the external organization.

ERROR : Subtask NeedsConfiguration execution failed: Configure Organization Relationship
Exchange was unable to communicate with the autodiscover endpoint for your Office 365 tenant. This is typically an outbound http access configuration issue. If you are using a proxy server for outbound communication, verify that Exchange is configured to use it via the “Get-ExchangeServer –InternetWebProxy” cmdlet. Use the “Set-ExchangeServer –InternetWebProxy” cmdlet to configure if needed.

The client did have a proxy and reverse proxy within their infrastructure and as the solution and technical design required the traffic from the Hybrid Exchange server should have direct route to the Internet, so it bypasses any proxyserver. I was able to double-check this with the Network Administrator and all was configured correctly as written in the technical design.

When we digged through the logging on the Hybrid server which is located in the D:\Program Files\Exchange Server\Logging\Update-HybridConfiguration directory. We found an error message:

Exception=The remote server returned an error: (407) Proxy Authentication Required

This error was thrown after running the Get-FederationInformation cmd-let and pointed the cause to a proxy server, or at least a proxy setting. After reading several TechNet articles we found out that the commands run by the HCW are run under the context of “Local System”. As such, these commands are subject to the proxy settings of the “Local System” user profile and not my administrator profile settings.

The default value of “Automatically Detect Settings” in the Internet Options is always “Enabled” and is configured on per unique user. So this configuration also applies to “Local System”. This default setting, combined with the client’s PAC file, the HCW was directing “Local System” to use the proxy server.

Resolution:
To fix this you have to download a tool like PsExec which can run Internet Explorer under the context of “Local System”. Once you are running IE under the local system user simply disable the setting and save changes. Run the following cmd-let:

psexec.exe -i -s -d “C:\Program Files\Internet Explorer\iexplore.exe” in CMD with administrative priviliges.

psexec_cmndlet

This workarround allowed me to bypass the proxy settings in the PAC-file the client used and succesfully complete the Exchange Hybrid Configuration Wizard. Have fun running the HCW! 🙂

Import distribution groups to Office 365: Exchange Online with PowerShell

Today we faced an issue where a client needed to migrate their GroupWise distribution groups to Office 365. Since there is no easy way doing this we developed a PowerShell script to automate this proces. Well, actually it are two scripts.

The scripts are divided in one, creating the distribution groups and part two is adding the members to the newly created groups. First we have to gather the input for creating the distribution groups in Office 365. For this I only used the required attributes for creating a distribution group.

$import = Import-Csv -Path “C:\temp\Create-DG.csv” -Delimiter “;”
foreach ($item in $import) {
New-DistributionGroup -Name $item.Name -DisplayName $item.DisplayName -PrimarySmtpAddress $item.PrimairyEmailAddress -Type $item.Type
Export-Csv -Path “C:\temp\New-DistributionGroup_LogFile_$(get-date -Format ddMMyyyy).csv”
}

Once the distribution groups are created we can head on adding the members to them using the PowerShell script below.

$import = Import-Csv -Path “C:\temp\Add-DGMembers.csv” -Delimiter “;”
foreach ($item in $import) {
Add-DistributionGroupMember -Identity $item.GroupName -Member $item.UPN -Verbose
Out-File -FilePath “C:\temp\Add-DGMembers_LogFile_$(get-date -Format ddMMyyyy).log”
}

As we can see both the scripts import a .csv file containing the content. The .csv files and the PowerShell scripts can be downloaded below.

DOWNLOAD HERE

Please note that the distribution groups can be either created on-premises in Active Directory and then synced to Windows Azure Active Directory (Office 365) or either directly created in Office 365 with the help of remote PowerShell. Based on your infrastructure and migration scenario it can differ which is the best way to go. Functionally there will be no difference for Exchange Online. However in some hybrid scenarios it can be best to create the distribution groups on-premises and sync them to Office 36 with the help of Azure Active Directory Sync (DirSync).

Filter OU’s to be synchronized to Office 365 with Windows Azure Active Directory Sync

When performing Office 365 deployments for most companies DirSync comes in the picture. Or as Microsoft prefers to call it, Windows Azure Active Directory Sync. Since most of the IT environments become polluted when time flies by most of my client’s prefer to perform a limited synchronization with DirSync.

As said earlier, most IT environments become polluted by time. As Active Directory Users & Computers is one of the most heavily administered you can imagine how much dirt sneaks in which makes it very interesting for businesses. Therefore Microsoft has a way to perform a limited DirSync based on OU (Organizational Unit) hierarchy and selection. For this we have to digg our way into ForeFront Identity Manager.

For this we have to open the FIM 2010 console by navigating to the following directory “C:\Program Files\Windows Azure Active Directory Sync\SYNCBUS\Synchronization Service\UIShell”.

Here you will find a executable called miisclient.exe. Run this application with “Run as administrator” priviliges. Make sure the account which initiates the request is member of the “Domain Admins” and the “Enterpirse Admins” security groups within your ADS forest. It’s also required to be a member of the local security group “FIMSyncAdmins” on the DirSync server.

Please refer to the image illustrated here for the instructions listed below.
FIM_console_instructions1
1. Click on “Management Agents” in the top ribbon.
2. Right click on the “Active Directory Connector” management agent and select “Properties”.
3. Click on “Configure Directory Partitions” on the left hand side of the menu.
4. Click on “Containers” and fill in the credentials of the local ADS service account.
5. After filling in the credentials a windows opens with the AD forest hierarchy. Here you can select the required Organizational Unit’s. Please refer to the image illustrated below.
FIM_console_instructions2

After selecting the prefered OU’s select OK and save the configuration. Next is waiting for DirSync to kick of a fresh Delta Sync. If you can’t wait then fire up PowerShell on the DirSync server and run the following two cmd-lets:

1. Import-Module DirSync
2. Start-OnlineCoexistenceSync -FullSync

Hope this helps fellow IT Professionals deploying succesfull Office 365 product. And obviously it is best to configure this filtering before Windows Azure Directory Sync synchronizes for the first time.

Convert security groups to mail-enabled and universal for Office 365 with PowerShell

When carrying out projects for Enterprise clients I commonly face challenges with companies not meeting the system requirements for Office 365. One of the most commonly seen missing requirements are on the Identity and Access Management part of Office 365.

When migrating legacy Identity and Access Management infrastructures to Office 365 you quickly bump in to Microsoft’s Active Directory Services (ADS). To migrate this service to Windows Azure Active Directory – which is part of every Office 365 license – you can use the Windows Azure Active Directory Sync tool. Or as most IT Professionals know it “DirSync”, this is a special edition of FIM.

Now back to businness. To migrate legacy security groups to Windows Azure Active Directory, for products such as Exchange Online it is a requirement to have a GroupScope of Universal.(see image below)

Get-ADGroup-GroupScope

Since most companies still use Global security groups these need to be converted. Therefore I use a PowerShell script which automates this proces. For this script to work, import the ActiveDirectory module in PowerShell or run the script with Active Directory Module for Windows PowerShell.

Clear-Host

if((Get-Module | where {$_.Name -eq “ActiveDirectory”}) -eq $null){
Import-Module ActiveDirectory
}
$scriptPath = split-path -parent $MyInvocation.MyCommand.Definition
Set-Location $scriptPath
Write-Output “Output will be stored in ” (Get-Location)

$SeaBase = “DC=corp,DC=local”
$SeaVal = “CN=Mailbox_*”
$SeaScope = “Subtree”
$GrpList = “ADSecGrp.csv”
$UniGrpList = “Uni_ADSecGrp.csv”
$strLogFile = “ErrorLog.txt”
$DomainAdmin = Get-Credential

#Search for all Groups that are of type Security and scope is Global and starts with “Mailbox_”
$SecGrps = Get-ADGroup -SearchScope $SeaScope -SearchBase $SeaBase -Filter {GroupCategory -eq “Security” -and GroupScope -eq “Global”}

foreach ($secGrp in $SecGrps) {
try {
$DN = $secGrp | Where-Object {$_.DistinguishedName -like $SeaVal}
$DN | Export-Csv $GrpList -Append
} catch {
throw
Break
}
}

(Get-Content $GrpList | Select-Object -Skip 1) | Set-Content $GrpList

Write-Output “Check $GrpList to verify all exported security Groups are of type Global”
Write-Output “Press Y to continue”
$selection = read-host
if ($selection -eq “y” -or $selection -eq “Y”){
Write-Output “$GrpList CSV File Checked….”
foreach($G in Import-Csv $GrpList){
try {
$D = $G.DistinguishedName
Get-ADGroup -Identity $G.SID
Set-ADGroup -Identity $G.SID -GroupScope Universal -Credential $DomainAdmin
} catch {
$ErrorMessage = $_.Exception.Message
Write-Output “Error converting for $D ..`n Error Message : $ErrorMessage” | Add-Content $strLogFile
Throw
Break
}
$DN = Get-ADGroup -Identity $G.SID
$DN | Export-Csv $UniGrpList -Append
}
(Get-Content $UniGrpList | Select-Object -Skip 1) | Set-Content $UniGrpList
Write-Output “Check $UniGrpList to verify all modified security Groups are of type Universal”
}else{
Write-Output “Script Stopped by User” | Add-Content $strLogFile
Break
}

As you can see the script contains several variables. With these you can define the scope of OU’s or name convention for existing security groups. When running the PowerShell script it builds up a CSV-file called Uni_ADSecGrp.csv. When paused you can open and check the file to see if it contains the groups which you wish to convert. If so, you can insert “Y” to the script and it proceeds running.

After we have succesfully changed the GroupScopes to Universal we can carry on and use the second PowerShell script which mail-enables the security groups so they meet the requirements for Exchange Online. Besides the conversion to mail-enabled it also hides the groups from the Global Address List.

Run this script on one of the legacy Exchange servers with the use of the  Exchange Management Shell.

Clear-Host

if((Get-Module | where {$_.Name -eq “ActiveDirectory”}) -eq $null){
 Import-Module ActiveDirectory
}

Add-PSSnapin Microsoft.Exchange.Management.PowerShell.E2010
 $env:ExchangeInstallPath\bin\RemoteExchange.ps1
Connect-ExchangeServer -auto

Write-Output “Output will be stored in ” (Get-Location)

$GrpList = “Final_ADSecGrp.csv”
$strLogFile = “enableErrorLog.txt”
$log = “AfterLog.txt”
$ErrorLog = “ErrorLog.txt”

foreach($G in Import-Csv “Uni_ADSecGrp.csv”){

try {
Get-ADGroup -Identity $G.SID

Enable-DistributionGroup -Identity $G.DistinguishedName -Alias $G.Name
Set-DistributionGroup -Identity $G.DistinguishedName -HiddenFromAddressListsEnabled $true
Get-DistributionGroup -Identity $G.DistinguishedName | Add-Content $Log
$x = Get-DistributionGroup -Identity $G.DistinguishedName
if($x -ne $Null){
Write-Output $G.DistinguishedName
}else{
Write-Output $G.DistinguishedName | Add-Content $ErrorLog
}
} catch {
$ErrorMessage = $_.Exception.Message
Write-Output “Error Enabl-DistributionGroup for $G.DistinguishedName …..`nError Message : $ErrorMessage” | Add-Content $strLogFile
throw
Break
}

}

Once you have succesfully executed the second script you can add these objects to your Windows Azure Directory Sync cycle. Please be aware that when you convert the groups, the groups may not contain unsupported characters such as namespaces or & characters.

Best of luck to you all with carrying out succesfull Office 365 deployments. Before I publish the post, I have thank to my colleague and teammate Dev Chaudhari for working on the scripting!

Change explicit User Principal Names to match Office 365 domain suffix

Most Enterprise Office 365 clients will use Active Directory Federation Services and Windows Azure Active Directory Sync, also known as DirSync for Single Sign-On functionality with Office 365.

Standard AD FS will use the on-premises UPN to access services in Office 365. Therefore Microsoft advises to make sure User Principal Name suffixes and e-mail adress suffixes match to make life simpler. Most ADS domains still use an internal routable domainname for instance contoso.local. However when implementing AD FS with Office 365 it permitted to have an “internet routable” domain suffix for instance contoso.com.

The best solution for this before implementing and running a DirSync is to create a new User Principal Name suffix to match your Office 365 domain suffix. This can be done by adding a new UPN suffix by going to:

  1. Open Active Directory Domains and Trusts
    2. Right click on the top level of the tree in the left pane and select properties
    3. Add the new internet routable UPN suffix e.i. contoso.com

Next step is to change the explicit User Principal Names for all the designated user objects in Active Directory which you plan to synchronize to Office 365. The easiest way to do this is with the help of allmighty PowerShell.

I wrote this easy one-liner which allows you to target a specific OU in Active Directory. Don’t forget to use the Active Directory Module for PowerShell.

Get-ADUser -Filter * -SearchBase ‘OU=Users,DC=fabrikam,DC=local’ -Properties userPrincipalName | foreach { Set-ADUser $_ -UserPrincipalName “$($_.samaccountname)@contoso.com”}

After succesfully running the cmd-lets you will notice the new UPN suffix is configured for the targeted user objects in ADS.