Configuring a multi-tenant federation with AD FS in a multi forest scenario with PowerShell

For weeks we have been working with Microsoft Premier Support and several product teams within Microsoft on a multi-forest to multi-tenant federation solution for Office 365 at two Dutch municipalites. There was some unclarity concerning supportabilty for our desired architecture at Microsoft, but as Microsoft calls it… this architecture qualifies for supportabilty. The fun part is, this scenario doesn’t require the provisioning of AD objects by hand, and allows you to use AADConnect to do this for you!

Now as the topology shows, we have two accounting forests where the AADConnect servers and Active Directory users reside. Each municipality has its own forest (forest B and forest C) and a configured a two-way full trust (forest-wide) to the resource forest (forest A). The Active Directory Federation Services (AD FS) farm resides in the resource forest (forest A).

Now the business requirement is having a single but high available AD FS farm in a resource forest, delivering an easy way of administering Identity Management for the long term. While at the same time delivering single sign-on functionality to all users working with Office 365 for each respected municipality.

Now the hard part here is the second federation to Office 365. The first federation configurated between the Microsoft Federation Gateway and your on-premises AD FS farm is pretty straight forward. And here is how it’s done:

  1. Log in to one of the AD FS Servers with an Domain Administrator account.
  2. You need to install the modules that are required for Office 365,
    1. Microsoft Online Service Sign-in Assistant for IT Professionals RTW
    2. Windows Azure Active Directory Module for Windows PowerShell (64-bit version
  3. Setup a Remote PowerShell connection to your tenant with an account having Global Administrator rights with this script;
    1. Import-Module MSOnline
      $O365Cred = Get-Credential
      $O365Session = New-PSSession –ConfigurationName Microsoft.Exchange -ConnectionUri https://ps.outlook.com/powershell -Credential $O365Cred -Authentication Basic -AllowRedirection
      Import-PSSession $O365Session
      Connect-MsolService –Credential $O365Cred

Once connected to the first tenant in Office 365 on the AD FS server run this cmd-let, be sure to use the -SupportMultipleDomains $true parameter.

Convert-MsolDomainToFederated -DomainName contoso.com -SupportMultipleDomain $true

The –SupportMultipleDomain parameter is needed since this is required for the multi-tenant configuration to work. This paramater makes sure that the federation is built with the correct IssuerUri set to https://contoso.com/adfs/services/trust/ instead of the Federation Service namespace (generally sts.domain.com) when not using this parameter. This is a vital requirement later on. To double-check this you can check the Claim Rules in AD FS management, the third rule should containt this claim:

c:[Type == “http://schemas.xmlsoap.org/claims/UPN“] => issue(Type = “http://schemas.microsoft.com/ws/2008/06/identity/claims/issuerid“, Value = regexreplace(c.Value, “^((.*)([.|@]))?(?<domain>[^.]*[.].*)$”, “http://${domain}/adfs/services/trust/“));

Now this was the first municipality for which contoso.com is the federated domain. You can download the script at the bottom of this blog.

Wait for a minute -or five- untill the federation kicks in and let’s carry on implementing the second federation…the real fun part!

First of all we need to export the token-signing certificate from the AD FS farm by PowerShell:

$tokenRefs=Get-AdfsCertificate -CertificateType Token-Signing
$tokenBytes=$certRefs[0].Certificate.Export([System.Security.Cryptography.X509Certificates.X509ContentType]::Cert)
[System.IO.File]::WriteAllBytes(“c:\temp\tokensigning.cer”, $certBytes)

Next we can establish a new Remote PowerShell session to the second tenant with the script shared in step one of this post. After that we configure the second federation with this PowerShell script.

$cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2(“C:\temp\tokensigning.cer”)
$certData = [system.convert]::tobase64string($cert.rawdata)
$dom=”fabrikam.com”
$url=”https://adfs.ResourceForestFDQN.com/adfs/ls/&#8221;
$uri=”http://fabrikam.com/adfs/services/trust/&#8221;
$ura=”https://adfs.ResourceForestFDQN.com/adfs/services/trust/2005/usernamemixed&#8221;
$logouturl=”https://adfs.ResourceForestFDQN.com/adfs/ls/&#8221;
$metadata=”https://adfs.ResourceForestFDQN.com/adfs/services/trust/mex&#8221;
#command to enable SSO
Set-MsolDomainAuthentication -DomainName $dom -Authentication Federated -ActiveLogOnUri $ura -PassiveLogOnUri $url -MetadataExchangeUri $metadata -SigningCertificate $certData -IssuerUri $uri -LogOffUri $logouturl -PreferredAuthenticationProtocol WsFed

Now the most beautiful part of this second implementation is that it only configures endpoints on the Microsoft Federation Gateway, and doesn’t touch our on-premises configuration. The magic third claim we talked about earlier is all we need for it to work!

Once configured, the configuration of both tenants can be validated using the ‘Get-MsolDomainFederationSettings’ cmdlet. The only difference when comparing the tenant configuration should be the ‘FederationBrandName’ and the ‘IssuerUri’ values.

Download the PowerShell scripts right here!

 

 

 

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

}

How to force a manual DirSync to Office 365 with AADConnect

Since the introduction of the renewed version of DirSync – called AADConnect nowadays – we have noticed great new functionalities. Depending upon the version that you are using to replicate Active Directory objects from on-premises Active Directory Domain Services to Office 365 Windows Azure Active Directory there are different commands that you will need to use.

Since June 2015 we have the release of AADConnect. As time of writing this blog the current version we’re on is 1.0.9125.0. Because the tool is under heavy development check out version history ocasionally on this website.

The default installation folder of AADConnect is C:\Program Files\Microsoft Azure AD Sync\Bin and this is where you can initiate a full or delta sync to Office 365.

deltasync_aadconnect

  1. Open PowerShell with administrative priviliges.
  2. Change the directory to folder containing the tool with the cmd-let cd “C:\Program Files\Microsoft Azure AD Sync\Bin” 
  3. To initiate a Full Syc to Office 365 run the cmd-let .\DirectorySyncClientCmd.exe initial staging 
  4. For a incremental or delta sync the cmd-let .\DirectorySyncClientCmd.exe delta 

Now be patient for 5 minutes for the new and edited objects to show up on the Office 365 portal. Depending on the amount of objects in ADDS and assigned server resources this action can take up to 15 minutes.

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.

SharePoint 2010 Search: The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

Last night we stumbled intoo an issue at one of our clients.The clients supplier had recently performed a lot maintenance activities in a maintenancewindow on their SharePoint 2010 environment. One of them was replacing the existing SSL certificates with a new wildcard certificate. The SharePoint farm exists of two WFE’s, one APP and a SQL server. The regular three-tier-farm you see alot.

Usually this change activity should not be a problem however, the supplier was somewhat to enthasiastic with replacing the SSL certificates. They unconsciously replaced the self-signed SharePoint Services SSL certificate on the SharePoint Web Services site in IIS with the new wildcard SSL certificate. Without knowing this history we started troubleshooting SharePoint Search which was causing issues. When browsing to the Search Service Application Administration component it showed this error message on the Administration Page:

The underlying connection was closed: Could not establish trust relationship for the SSL/TLS secure channel.

Users were not getting back any search hits and when browsing to the Content Sources in Central Administration, SharePoint threw a Correlation ID.

After going through the logging and finding the error related to the correlation ID we noticed this error in the ULS logging:

An operation failed because the following certificate has validation errors:\n\nSubject Name: CN=*contoso.com, OU=IT, O=”Contoso”, L=Paris, S=Paris, C=FR\nIssuer Name: CN=Thawte SSL CA – G2, O=”Thawte, Inc.”, C=US\nThumbprint: AB12CD34XX123456ABCDEFG123XXX\n\nErrors:\n\n SSL policy errors have been encountered.  Error code ‘0x2’

This error pointed us to SharePoint Search trying to communicate over HTTPS to it’s back-end web-services with the use of the clients wildcard SSL certificate and failing. After troubleshooting further we noticed the wilcard certificate was indeed binded on the HTTPS listener on port 32844. Now you would think, that’s an easy fix to do. Just remove the certificate on the binding and there you go. Well, when configuring a SSL certificate on a binding in IIS you are required to select a SSL Certificate located in the servers Personal Certificate store. And that’s not the correct store for SharePoint web-services.

The rootcause:

SharePoint uses it’s own “SharePoint Services” self-signed certificate to securely communicate over HTTPS with it’s web-services and other farm memberservers. You can find this specific certificate looking in the Local Computer Certificate Store using the MMC snapin. I discovered a folder called SharePoint which had three certificates in it, all issued by the Sharepoint Root Authority:

  • SharePoint Security Token Service
  • SharePoint Security Token Service Encryption
  • SharePoint Services

The solution:  

Now to undo the faulty configuration and reconfigure the correct “SharePoint Services” SSL certificate on the SharePoint Web Services IIS site – which can’t be done with the IIS Manager Console –  you can either use good old netsh command-line or use PowerShell. Now the last method is the method I personally prefer so that’s what you’re getting.. =)

$iisBinding = “SharePoint Web Services”
$webservice = Get-WebBinding -name $iisBinding -protocol “https” -port 32844
if ($webservice)
{
$pfx = get-childitem cert:\\localmachine\sharepoint | where { $_.subject -contains “^CN=SharePoint Services” }
if (!$pfx)
{
throw “No certificate found with the name “SharePoint Services” in the SharePoint certificate store in MMC. The script has stopped”
}

[void]$webservice.AddSslCertificate($pfx.ThumbPrint, “SharePoint”)
}
else
{
throw “The certificate cannot be assigned to the designated IIS Binding. Check servers eventviewer for further information.”
}

if (!(Get-WebBinding -name $iisBinding -protocol “http” -port 32843))
{
New-WebBinding -name $iisBinding -ip “*” -port 32843 -protocol “http”
}

This script looks for an existing IIS site or binding with the port 32844 (which SharePoint uses OOTB). Once found it checks whether it can find an existing valid SSL certificated in the computer which contains the name “SharePoint Services”. If both are found it adds the correct certificate to the designated SharePoint Web Services binding. An action which can’t be done via the ISS Management Console.

This recovers the Search Service Application to it’s original healthy state. In our specific scenario we had to run a “Full Crawl” to on all the Content Sources since the index became inconsistent too. I always use this small PowerShell script to initiate the Full Crawls:

$searchapp = Get-SPEnterpriseSearchServiceApplication “Search Service Application” 
Get-SPEnterpriseSearchCrawlContentSource -SearchApplication $searchapp | where-object { $_.Type -contains “Sharepoint”} | foreach-object { $_.StartFullCrawl() }

If this still doesn’t fix your issue you’re being really unlucky. You will still be getting this error message prompted when initiating searchresults:

“Property doesn’t exist or is used in a manner inconsistent with schema settings” and not receiving any People results.

But don’t worry, there’s still one option to be checked. We found out that after this issue is dependant on the actual webparts used by search (including People Search). For this the solution in the end was to edit the People Core Result Web Part on the search results page and expand the “Display properties” and make sure “Use Location Visualization” is checked.

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!

SharePoint User Profile Service Application: Exception while trying to migrate account. The user does not exist or is not unique.

A while ago I was facing an issue with NetBIOS names when configuring the SharePoint Server User Profile Service Application. In this particular scenario the NetBIOS name was different from the domainname. For instance NetBIOS namespace would be CON\username and the domainname would be CONTOSO\username. The errors which were thrown on the applicationserver:

The extensible extension returned an unsupported error.
The stack trace is:

“System.Reflection.TargetInvocationException: Exception has been thrown by the target of an invocation. —> System.AggregateException: One or more errors occurred. —> Microsoft.Office.Server.UserProfiles.UserProfileException: Exception while trying to migrate account ‘CON\Username’ to ‘CONTOSO\Username’. —> Microsoft.SharePoint.SPException: The user does not exist or is not unique. —> System.Runtime.InteropServices.COMException: The user does not exist or is not unique.<nativehr>0x81020054</nativehr><nativestack></nativestack>
at Microsoft.SharePoint.Library.SPRequestInternalClass.SelectSitesAndUserInfoForMigration (Object& pvarContentDsns, Object& pvarContentIds, String bstrOldLogin, String bstrNewLogin, String bstrFullUserKey, Boolean bEnforceSidHistory, Guid guidSubscriptionId, String& pbstrNewLogin, Byte[]& ppsaOldSid, Byte[]& ppsaNewSid, Object& pvarSidHistory, Object& pvarSiteIds)at Microsoft.SharePoint.Library.SPRequest.SelectSitesAndUserInfoForMigration (Object& pvarContentDsns, Object& pvarContentIds, String bstrOldLogin, String bstrNewLogin, String bstrFullUserKey, Boolean bEnforceSidHistory, Guid guidSubscriptionId, String& pbstrNewLogin, Byte[]& ppsaOldSid, Byte[]& ppsaNewSid, Object& pvarSidHistory, Object& pvarSiteIds)
— End of inner exception stack trace —
at Microsoft.SharePoint.SPGlobal.HandleComException(COMException comEx)
at Microsoft.SharePoint.Library.SPRequest.SelectSitesAndUserInfoForMigration(Object& pvarContentDsns, Object& pvarContentIds, String bstrOldLogin, String bstrNewLogin, String bstrFullUserKey, Boolean bEnforceSidHistory, Guid guidSubscriptionId, String& pbstrNewLogin, Byte[]& ppsaOldSid, Byte[]& ppsaNewSid, Object& pvarSidHistory, Object& pvarSiteIds)
at Microsoft.SharePoint.Administration.SPFarm.MigrateUserOrGroup(Guid subscriptionId, String oldLogin, String newLogin, Boolean usersOnly, Boolean enforceSidHistory)
at Microsoft.SharePoint.Administration.SPFarm.MigrateUserAccount(Guid subscriptionId, String oldLogin, String newLogin, Boolean enforceSidHistory)
at Microsoft.Office.Server.UserProfiles.UserProfile.MigrateUser(String newAccountName, Boolean fullMigration)
— End of inner exception stack trace —

The default configuration and behaviour of the User Profile Service Application does not include the NetBIOS namespace. When you would address the Service Application with PowerShell with Get-SPServiceApplication you would see the property NetBIOSDomainNamesEnabled set to 0 which is disabled.

To enable the NetBIOS namespace for SharePoint you have to recreate the Synchronization Connection to ADDS in the User Profile Service Application. This is necessary since in the creation process of this connection the Configuration Naming Context (CNC) is written to the FIM configuration and SQL database behind it.

  1. Delete the existing faulty Synchronization Connection in the User Profile Service Application.
  2. Open the SharePoint 2013 Management Shell with administrative rights.
  3. Run Get-SPServiceApplication and copy the GUID of the User Profile Service Application.
  4. Run this script in with the correct GUID.

    $UserProfile = Get-SPServiceApplication –Id <GUID>

    $UserProfile.NetBIOSDomainNamesEnabled=1

    $UserProfile.Update()

  5. Create a new Synchronization Connection with Active Directory Domain Services.
  6. Run a new and first “Start Profile Synchronization”.

Once the sync has completed eveyones SAMAccountName should be including the correct NetBIOS namespace of CON\username.

Offboarding mailboxes back to on-premises Exchange with Office 365

Most companies use the built-in migration feature in the Office 365 Portal for onboarding mailboxes to the cloud. This has been recently upgraded with alot of new features such as batches and migration end-points etc.

However a logical question is, what about migrating mailboxes back to our on-premises Exchange organisation? Creating those end-points can sometimes be difficult. To make life easier I use this simple PowerShell script. Before you can run the script you first have to connect to Remote PowerShell. For that please follow the instructions described here.

$opcred = get-credential domain\domainadmin
Get-Mailbox -Identity username@contoso.com | New-MoveRequest -OutBound -RemoteTargetDatabase ‘Database01’ -RemoteHostName ‘hybrid.contoso.com’ -RemoteCredential $opcred -TargetDeliveryDomain ‘contoso.com’

As you can see we define several parameters. Most of them should make sense to you, however I want to highlight that in a hybrid scenario you must use the database on your hybrid server. The RemoteHostName parameter is your hybrid endpoint.

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).