ADFS 2.0 cloud exchange exchange online mcm Office 365 proxy

Adding Servers to ADFS 2.0 Farms – Subject Alternative Name Issues

When you add additional servers to an ADFS 2.0 farm and you have used a subject alternative name from your certificate to create the first server in the farm the additional servers will not be able to join the farm. If you have used the subject name on the certificate all works fine.
You get the following error message:

The Subject name of the SSL certificate for the Default Web Site on this computer should match the name of the Federation Service to which you are trying to join this computer.

You also get the following error:

No certificates matching the Federation Service name were found in the Local Computer certificate store. Install the certificate that represents your Federation Service name in the Local Computer certificate store, and then try again.

The help file for ADFS 2.0 says “the actual name text is determined by either the Subject field or, if necessary, the Subject Alternative Name field of the certificate”, but the addition of additional servers does not work if you have used a Subject Alternative Name.
So how do you get around this. With thanks to Tim Heeney and Roberto Martinez Lima from Microsoft and the rest of the class on the inagural Office 365 Microsoft Certified Master class (a subset of the Exchange 2010 MCM program) we worked out the answer. You need to install the additional servers from the command line – the problem is a user interface bug in the ADFS 2.0 setup program.

FsConfig.exe JoinFarm /PrimaryComputerName ADFS-SRV-1 /ServiceAccount fabrikam\adfsservice /ServiceAccountPassword password /CertThumbprint “ef 72 a6 78 c0 ab 4a bf 07 10 7e e4 86 f5 5e ba 2a 3c 99 6b”

The thumbprint needs to be the thumbprint of the certificate used on the first ADFS server and imported into the computer certificate store on the additional ADFS servers.
On running the FsConfig command above you should get a series of green Passed statements. Existing databases can be removed with /CleanConfig switch. A yellow warning about an existing website can be ignored unless you have broken the website previously!

exchange exchange online Office 365

Mismatched Archive GUID for Moving Archive to Office 365

If you create an archive in Office 365 for a mailbox on-premise you might find that it does not work – the actual archive is not (as of time of writing) created correctly. What’s the way around it? The way around it is to create the archive on-premise and then move the archive to the cloud.

But you get this error message:

Recipient ‘Aaron Con’ has mismatched archive GUID (19ec252e-00b2-463f-b9b4-7012fabfa60e). Expected value: 00000000-0000-0000-0000-000000000000.
Click here for help…
Exchange Management Shell command attempted:
‘c607a1af-5608-424d-8ea1-447dcad60003’ | New-MoveRequest -Remote -ArchiveOnly -RemoteHostName ‘’ -ArchiveDomain ‘’

This is caused because the archive has been created on-premise and then before this change is synchronised to the cloud the move occurs. The actual steps to do the above are as follows:

  1. Create local archive
  2. Synchronise changes to the cloud
  3. Move the archive to the cloud
  4. Wait until the move request completes (run Get-MoveRequest identity via Remote PowerShell to Exchange Online)
  5. Check that archive in cloud is provisioned with Get-MailUser identity | FL *archive* run via Remote PowerShell to Exchange Online. This will take a few minutes before the ArchiveDatabase value is populated.
  6. Synchronise changes again, so that the changes in the cloud are pushed back to on-premise
  7. Login as the user and access the cloud archive.
bpos dirsync exchange Office 365

Office 365 DirSync Schedule

The DirSync process sync’s every three hours by default, with  a random number between 1 and 10 minutes is added to the SyncTimeInterval to provide an additional time buffer to this three hour period.
This schedule can be changed by editing Microsoft.Online.DirSync.Scheduler.exe.Config in C:\Program Files\Microsoft Online Directory Sync. Change to read a different value for hours:minutes:seconds and restart the Microsoft Online Services Directory Synchronization Service.

Note that increasing the time sync interval will result in changes to the Active Directory not being synced until this time period has passed and so the longer the interval the greater risk that objects disabled or removed in the on-premise Active Directory are not replicated to Office 365 and therefore remain as a valid account within Office 365.

2010 exchange federation Office 365 organization relationships powershell proxy

Free/Busy Cross-Forest Working One Way Only

Or indeed, not working at all! I had the issue of it working one way only (On-Premise Exchange organization > Office 365) but the other way (cloud to on-premise) did not work at all.

The answer is shown in this video

This covers the reasons why Free/Busy (and the other federation features of MailTips, archive and move mailbox might not work both ways in a Hybrid Coexistence setup for Office 365 or between two Exchange on-premise organizations.

The reason I found was the Organization Relationship contained the wrong list of domains. There are three domains (at least) that are needed in the organization relationship. These are:

  • Primary SMTP Namespace Domain (i.e.
  • Namespace for other organization (i.e.
  • Exchange Delegation domain (i.e.

In the organization relationship on-premise (or Org A if you are doing two on-premise organizations) set the following domains after the relationship is created. This includes the primary SMTP namespace and the service namespace for the other organization. This can be set with the following Exchange Management Shell cmdlet:

Set-OrganizationRelationship -Identity “To Cloud” -DomainNames “”,”” -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True –TargetOwaUrl -ArchiveAccessEnabled $True –MailboxMoveEnabled $True

In Org B (or on Office 365) use a similar cmdlet, but use the Exchange Delegation namespace and the primary SMTP domain. Also Office 365 does not let you set the MailboxMoveEnabled property to $True

Set-OrganizationRelationship -Identity “To On-premises” -DomainNames “”,”” -MailTipsAccessEnabled $True -MailTipsAccessLevel All -DeliveryReportEnabled $True -ArchiveAccessEnabled $True

Supposedly Service Pack 2 for Exchange 2010 will do all this and more for you with the Hybrid Configuration Wizard, but its always useful for troubleshooting to discover what changes and why when you run a wizard to do things!

2010 2013 64 bit active directory ADFS ADFS 2.0 certificates exchange exchange online https isa mcm microsoft Office 365 pki tmg

Publishing ADFS Through ISA or TMG Server

To enable single sign-on in Office 365 and a variety of other applications you need to provide a federated authentication system. Microsoft’s free server software for this is currently Active Directory Federation Server 2.0 (ADFS), which is downloaded from Microsoft’s website.

ADFS is installed on a server within your organisation, and a trust (utilising trusted digital certificates) is set up with your partners. If you want to authenticate to the partner system from within your environment it is usual that your application connects to your AFDS server (as part of a bigger process that is better described here: But if you are outside of your organisation, or the connection to ADFS is made by the partner rather than the application (and in Office 365 both of these take place) then you either need to install ADFS Proxy or publish the ADFS server through a firewall.

This subject of the blog is how to do this via ISA Server or TMG Server. In addition to configuring a standard HTTPS publishing rule you need to disable Link Translation and high-bit filtering on the HTTP filter to get it to work.

Here are the full steps to set up AFDS inside your organisation and have it published via ISA Server – TMG Server is to all intents and purposes the same, the UI just looks slightly different:

  1. New Web Site Publishing Rule. Provide a name.
  2. Select the Action (allow).
  3. Choose either a single website or load balancer or use ISA’s load balancing feature depending on the number of ADFS servers in your farm.
  4. Use SSL to connect:
  5. Enter the Internal site name (which must be on the SSL certificate on the ADFS server and must be the same as the externally published name as well). Also enter the IP address of the server or configure the HOSTS files on the firewall to resolve this name as you do not want to loop back to the externally resolved name:
  6. Enter /adfs/* as the path.
  7. Enter the ADFS published endpoint as the Public name (which will be subject or SAN on the certificate and will be the same certificate on the ADFS server and the ISA Server):
  8. Select or create a suitable web listener. The properties of this will include listening on the external IP address that your ADFS namespace resolves to, over SSL only, using the certificate on your ADFS server (exported with private key and installed on ISA Server), no authentication.
  9. Allow the client to authenticate directly with the endpoint server:
  10. All Users and then click Finish.
  11. Before you save your changes though, you need to make the following two changes
  12. Right-click the rule and select Configure HTTP:
  13. Uncheck Block high bit characters and click OK.
  14. Double-click the rule to bring up its properties and change to the Link Translation tab. Uncheck Apply link translation to this rule:
  15. Click OK and save your changes.

ADFS should now work through ISA or TMG assuming you have configured ADFS and your partner organisations correctly!

To test your ADFS service connect to your ADFS published endpoint from outside of TMG and visit https://fqdn-for-adfs/adfs/ls/idpinitiatedsignon.aspx to get a login screen

exchange exchange online Office 365 powershell

PowerShell Script To Update All UPN’s

This quick script will process all your user accounts in the domain and change the UPN for each of them to a new one, which you need to specify in the script in advance of running it. This script is useful for Office 365 Rich Coexistence (Hybrid) scenarios which require that the UPN (User Principal Name) for each account matches their email address.
Optionally you can add the UPN that you are going to use (your verified vanity domain in Office 365) to Active Directory Domains and Trusts. Adding the UPN extension to Active Directory Domains and Trusts allows you to select the UPN extension whilst creating users in this program, but you do not need to add the extension to Domains and Trusts to change a users UPN using the below script.
To run the script copy the below to a text file, saving it as Update-UPN.ps1. Change Then run this script from an Exchange Management Shell.
$upnExt = Read-Host “Please enter your UPN extension (excluding @)”$users = Get-User * -ResultSize Unlimited    
foreach($user in $users)
$UPN = “$($user.sAMAccountName)@” + $upnExt
Write-Host “Setting ” $UPN
$user | Set-User -UserPrincipalName $UPN

Tip: Comment out the Write-Host line with # if you do not want feedback on each user changed – it will make the script go much faster
Tip: For testing purposes change the * in the first line to the name of a test user or do something like test* to change all users starting with the word “test” in their username.

2007 2010 2013 ADFS ADFS 2.0 certificates exchange exchange online https hybrid IAmMEC ISA Server 2006 mcm Office 365 SSL tmg

Changing ADFS 2.0 Endpoint URL for Office 365

If you are configuring single sign-on for Office 365 then you will need a server running Active Directory Federation Services 2.0 (ADFS 2.0). When you install this you are asked for a URL that acts as an endpoint for the ADFS service, which if you are publishing that endpoint through a firewall such as TMG needs to be on a mutually trusted certificate as either the subject name or alternative subject name.

The documentation uses which means you need to have this as a valid name of the certificate. I use StartCom SSL, which provide cheap certificates (approx. $100 for as many certificates as you like), but to change a certificate to add an additional alternative subject name requires revoking the current cert, and that comes at additional cost.

So I have a certificate with lots of name on it for my domain, just not so I set about changing the endpoint in ADFS 2.0

Firstly open the ADFS 2.0 administrative console and select the root note:


Click Edit Federation Service Properties in the Action Pane and modify the three values on the General tab:


After clicking OK, restart the AD FS 2.0 Windows Service.

After the restart, create a new Token-Signing Certificate and Token-Decrypting Certificate. These are self signed certificates. To allow you to add these you need to turn off automatic certificate rollover if enabled. This can be done from PowerShell using Set-ADFSProperties –AutoCertificateRollover $false and this cmdlet is available in Windows PowerShell Modules in the Administrative Tools menu.

To update Office 365 start the Microsoft Online Services Module for Windows PowerShell, installed as part of the Office 365 rich co-existence process. In this PowerShell window type Update-MsolFederatedDomain –DomainName You will also need to login to Office 365 in this window first (Connect-MsolService) and set PowerShell with the name of the ADFS server (Set-MsolADFSContext –Computer ADFS_ServerName). Type Get-MsolFederatedDomain –DomainName to ensure that the returned URL’s and certificates are correct.

Now its time to update the TMG rule, or create a new one. The listener in TMG must have the same third party certificate and be for HTTPS with the Public Name matching the certificate subject/subject alternative name and the Path value set to /adfs/*. The To page needs to be set with the same URL and internal IP address of the ADFS 2.0 server.


And that should be it – after the Update-MsolFederatedDomain –DomainName has completed both sides of the federation trust are aware of the certificate change and automatic login to should work.