Windows 10 Enterprise E3 CSP - Activation Gotchas!

So Microsoft introduced the concept of Windows 10 Enterprise E3 or E5, which can only be purchased from CSPs - https://docs.microsoft.com/en-us/windows/deployment/windows-10-enterprise-e3-overview

The technical challenge is that the activation of Windows 10 Enterprise E3 (from Windows 10 Pro OEM) is not done using a product key, but requires Azure AD device registration - OR - Azure AD Join. These two things are fundamentally very different, and requires very different technical implication to work.

Scenario: Customer has bought a lot of replacement desktops, and they come with Windows 10 Pro OEM.  They bought Secure Productivity Enterprise E3 (SPE E3) from a CSP, which comes with Windows 10 Enterprise E3.

Customer requirement: The new computers will continue to be on-premises AD joined. The Windows 10 Enterprise activation should happen automatically and require no user intervention. The users shouldn't need to do anything different from Windows 7 - i.e. not use User Principal Name (UPN) to sign on, nor needing to do any AAD Join manually. Because this computer will be on-premises AD joined, it is not possible to simultaneously joined to Azure AD as well.


High level steps:

1. Implement Azure AD Connect. Ensure that user accounts (who will log onto the Windows 10 computers) and Windows 10 computer accounts are synced
2. Create the Service Connection Point for Azure AD automatic device registration. Follow instruction located here (https://docs.microsoft.com/en-us/azure/active-directory/active-directory-conditional-access-automatic-device-registration-setup) 
1. Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1";
2. $aadAdminCred = Get-Credential;
3. Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred;
3. Deploy WPAD in your environment. Windows 10 does not respect Internet Explorer proxy settings and the only way to get this working is deploying WPAD. 
4. Ensure that "licensing.mp.microsoft.com" can be accessed from the Windows 10 clients 
5. And now for the secret sauce - make sure that the GPO for "Do not connect to any Windows Update Internet locations" is TURNED OFF!

In the Microsoft documentation for Azure AD automatic device registration, it is mentioned that the GPO for "Automatically workplace join client computers" can be used to control the rollout - but based on testing, this is no longer required for Windows 10 1607 (Anniversary Update) onwards. 

The requirement to access licensing.mp.microsoft.com and the related GPO "Do not connect to any Windows Update Internet locations" is a major surprised for me, as this is not mentioned anywhere, not even in forums.

So hope this would help someone out there.

Bonus tip: to confirm Azure AD automatic device registration is successful, on the Windows 10 computer, look at event viewer > Applications and Services Logs > Microsoft > Windows > User Device Registration.

Bonus tip 2: also to confirm, run the following command line: dsregcmd /status - more information here https://docs.microsoft.com/en-us/azure/active-directory/active-directory-device-registration-troubleshoot-windows

Exchange 2007 and Exchange Online Free/Busy Issue

I can't sing higher praises on the Exchange Hybrid Free/Busy Troubleshooter - available here https://support.microsoft.com/en-au/help/10092/troubleshooting-free-busy-issues-in-exchange-hybrid-environment

It got me out of a jam that was especially perplexing.

So I have an Exchange 2007 environment, and the customer would want to move all mailboxes to Exchange Online, but they want to deploy Exchange Hybrid because "Big Bang" doesn't work for them.

So I put in an Exchange 2013 "hybrid" server and ran HCW. All went fine except when an Ex07 user tries to query free/busy for a cloud/EXO user, the dreaded grey bar "No Information" is shown.

FIX: Exchange 2013's EWS InternalURL is set to the wrong URL - in my case, it was pointing to the UAG 2010's listener, which still publishes OWA 2007. So I did the following to fix it:

• Update Exchange 2013 EWS InternalURL to internal FQDN (so the Exchange 2007 can locate it) - EAC > Servers > Exchange 2013 Server > EWS (Default Web Site) > Internal URL Then perform IIS reset
• Removed the availability space object - Remove-AvailabilityAddressSpace -Identity ‘tenantname.mail.onmicrosoft.com' 
• Recreate the availability space object - Add-AvailabilityAddressSpace -ForestName tenantname.mail.onmicrosoft.com' -AccessMethod 'InternalProxy' -UseServiceAccount $true -ProxyUrl https://exchange2013internalFQDN.company.com/ews/exchange.asmx

HCW v3 Stuck at "Adding Federated Domain"

Exchange Hybrid Configuration Wizard - always interesting times every single time I run this wizard.

My customer has three public facing domains that is required as part of the Exchange Online migration. I've added them into Verified Domain in Office 365 portal, ran HCW v3, added the TXT records required for Microsoft Federation Gateway, and when I clicked on "Verify TXT record" button, all 3 domain changed into "TXT record found", and the first domain proceed to be stuck at "Adding federated domain".

Looking into the HCW log (always a good place to start with %appdata%\Roaming\Microsoft\Exchange Hybrid Configuration\), the following error was found:

2017.04.20 01:08:12.023 *ERROR* [Client=UX, Page=DomainProof, Thread=17] Microsoft.Online.CSE.Hybrid.Provider.PowerShell.PowerShellInvokeException: PowerShell failed to invoke 'Set-FederatedOrganizationIdentifier': Unable to reserve domain "FYDIBOHF25SPDLT.company.com" for Application Identifier "000000004C04A704".  Detailed information: "A Windows Live ID error occurred. Detailed information: "PassportError: Passport error.".". ---> System.Management.Automation.RemoteException: Unable to reserve domain "FYDIBOHF25SPDLT.company.com" for Application Identifier "000000004C04A704".  Detailed information: "A Windows Live ID error occurred. Detailed information: "PassportError: Passport error.".".

                                   --- End of inner exception stack trace ---

                                   at Microsoft.Online.CSE.Hybrid.PowerShell.RemotePowershellSession.RunCommandInternal(Cmdlet cmdlet, SessionParameters parameters, Int32 millisecondsTimeout, PowerShellRetrySettings retrySettings, Boolean skipCmdletLogging)

                                   at Microsoft.Online.CSE.Hybrid.Session.PowerShellOnPremisesSession.SetFederatedOrganizationIdentifier(SmtpDomain accountNamespace, String delegationTrustLink, SmtpDomain defaultDomain)

                                   at Microsoft.Online.CSE.Hybrid.App.ViewModel.Pages.DomainProof.DomainInfo.AddFederatedDomain(IOnPremisesSession session, AppData appData)

                                   at System.Collections.Generic.List`1.ForEach(Action`1 action)

                                   at Microsoft.Online.CSE.Hybrid.App.ViewModel.Pages.DomainProof.VerifyActivity(IOnPremisesSession session, IEnvironment environment)

Restarting HCW did not help.

Resolution: Verify one domain at a time. In the page "Select the domains that you want to be part of your Hybrid Configuration", pick only one domain, and click Next, and proceed to verify that domain. Using the Back button, go back and pick another one (and unselecting the previous one) and verify that domain, and repeat for the last domain.

Hope this helps someone.

Missing ComputerName Field in Azure (ARM)

Have you noticed that some of your VMs in Azure ARM is missing a ComputerName field? All you get is a dash "-", like:

It turns out that you probably uploaded a non-generalized VHD (aka - it was not sysprepped). In Microsoft terms, this is also known as "specialized" VHD.

According to Microsoft, this is because the "OSProfile" field is missing, which is by design because this is a specialized image. One can only specify the OSProfile field when creating VMs using a generalized image.

Resolution: This is unfortunately a known issue and there is no way around it.

With a VM created from a specialized image the OSProfile field is set using the command "Set-AzureRMVMOperatingSystem". For example, to set it Windows, the following command is run:

Set-AzureRmVMOperatingSystem -VM $vmConfig -Windows

For more information about specialized image and generalized images in Azure:

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-create-vm-generalized/

https://azure.microsoft.com/en-us/documentation/articles/virtual-machines-windows-create-vm-specialized/

Microsoft Word: Continuous Heading Numbering

I seem to constantly struggle with keeping the numbering in headings straight. I have read various articles on this but this article is the best way of doing this:

https://blogs.msdn.microsoft.com/timid/2013/08/29/stupid-microsoft-word-trick-multilevel-numbered-headings/

https://wordknowhow.wordpress.com/2013/01/30/how-to-use-multilevel-numbered-headings-in-the-word/

Works with Microsoft Office 2016 too!

Azure Site Recovery - Random Field Notes

Just some notes on random knowledge I picked up that I did not see on official Microsoft documentation.

Scenario:

• Azure Resource Manager model (ARM)
• VMware to Azure (and back)
• vCenter and vSphere 5.5

Field Notes:

• Make sure all protected VMs have .NET Framework 3.5.1 installed, as it is required by Mobility Service. Mobility Service push install will fail with cryptic errors if this is not met,
• Make sure you patch your if you have vSphere (ESXi) 5.0 to 5.5 make sure it is patched to the levels - for more information (https://kb.vmware.com/selfservice/microsites/search.do?language=en_US&cmd=displayKC&externalId=2059053):
• ESXi 5.5, Patch Release ESXi550-201410001
• ESXi 5.1 Update 2
• ESXi 5.0 Patch Release ESXi500-201401001

Regarding the VMware patch, it is very important as your entire VMware farm (yes, every hosts in your farm!) will go into purple screen of death (PSOD) randomly when installing your Configuration Server or when protecting (replicating) VMs into ASR.

Azure Traffic Manager - CNAME Flattening

Scenario: You have moved some VMs into the cloud, where they serve your website. You have several VMs which are load balanced within one Azure region, and another bunch of identical VMs in another Azure region for high availability reasons. You deployed an Azure Traffic Manager to load balance between both Azure regions. Your Azure Traffic Manager URL is mywebapp.trafficmanager.net  and your website's domain is company.com.

Issue: When you try to create the CNAME "mywebapp.trafficmanager.net" record for "company.com", your DNS provider will reject it, saying that it violates RFC1912 - which states that:

• A CNAME record is not allowed to coexist with any other data,
• If a CNAME RR is present at a node, no other data should be present; this ensures that the data for a canonical name and its aliases cannot be different.

"company.com" type of record is commonly known as (all terms are interchangeable):

• Root URL
• Apex URL
• Naked URL

The alternative would be to use "www.company.com" instead and but your company have probably invested a lot of money on SEO to ensure that "company.com" shows up high in search ranking results.

Resolution: At the moment, CloudFlare seems to be your best bet. They introduced "CNAME flattening" back in March 2014 which allows exactly the scenario we need.

Read more about CNAME Flattening here:

• https://support.cloudflare.com/hc/en-us/articles/200169056-CNAME-Flattening-RFC-compliant-support-for-CNAME-at-the-root
• https://blog.cloudflare.com/introducing-cname-flattening-rfc-compliant-cnames-at-a-domains-root/

I've tested it with Azure Traffic Manager and it works perfectly.

Error Creating Cross Subscription VNet-to-VNet Connection on Azure Resource Manager Using PowerShell

So you are trying to create a VNet to VNet connection across subscriptions in Azure Resource Manager. The official documentation states that this cannot done by portal, and only PowerShell is supported:

https://azure.microsoft.com/en-us/documentation/articles/vpn-gateway-vnet-vnet-rm-ps/

When you run the final piece of code to create the connection:

$vnet1gw = New-Object Microsoft.Azure.Commands.Network.Models.PSVirtualNetworkGateway
$vnet1gw.Name = "VNet1GW"
$vnet1gw.Id   = "/subscriptions/b636ca99-6f88-4df4-a7c3-2f8dc4545509/resourceGroups/TestRG1/providers/Microsoft.Network/virtualNetworkGateways/VNet1GW "
New-AzureRmVirtualNetworkGatewayConnection -Name $Connection51 -ResourceGroupName $RG5 -VirtualNetworkGateway1 $vnet5gw -VirtualNetworkGateway2 $vnet1gw -Location $Location5 -ConnectionType Vnet2Vnet -SharedKey 'AzureA1b2C3'

You get the following error message:

UInt64 -> Nullable`1
System.UInt64 -> System.Nullable`1[[System.Int64, mscorlib .....

I was running Azure PowerShell 1.6.0 at the time.

Fix: Upgrade to Azure PowerShell 2.0.0 (download here).

To check your Azure PowerShell version, run the following script:

(Get-Module -ListAvailable | Where-Object{ $_.Name -eq 'Azure' }) `
| Select Version, Name, Author, PowerShellVersion  | Format-List;

Office 2013 Cannot Sign Into Office 365 with Functional ADFS Federated Domain

You deployed ADFS. You converted your Office 365 verified domain into federated domain. Single Sign On works on Internet Explorer inside the corporate network.

You sit back and relax and pat your back for a good job.

Then someone rings in saying that they:

1. Cannot open a document from SharePoint Online using "Open with Word" option
2. Cannot sign into Office 365 from Microsoft Word (or any other Office programs). The sign in screen sits there, and complains that it does not recognise your username or password, although the user swears on the life of all their children that they have entered the correct credentials
3. It was working fine before (or maybe not).

The fix is to blow away everything under the following registry key:

[HKEY_CURRENT_USER\Software\Microsoft\Office\15.0\Common\Identity\Identities\]

You might want to back it up, but it's pretty harmless (for me anyway).

Restart your computer, and try signing into Office 365 in Office programs - it should work now.

Azure Active Directory Connect - OU Filtering not working as intended

I have recently encountered an Azure AD Connect sync engine that refuses to respect the recent changes to exclude an OU that was previously included.

Azure AD Connect version in question is 1.1.130.0 - April 2016

If you are wondering how to exclude OUs, go to Synchronization Service > Connectors > pick your Active Directory connector > Properties > Configure Directory Partitions > Containers button > enter your Azure AD Connect service account password:

You then wait for the next sync cycle or manually force the sync cycle, and yet you noticed that the objects are not being disconnected from the metaverse, and continue to sync to Azure AD.

To fix this, simply restart the "Microsoft Azure AD Sync" service and wait for the next sync cycle.

Bonus tip:

A grey box with a tick = objects in that OU (not the sub OU) will be synced:

A grey box (without a tick) = objects in that OU will not be synced, but some sub-OUs are selected for sync.

OWA Redirection Does Not Work for Migrated Mailbox to Exchange Online

So you have migrated a user to Exchange Online (via hybrid configuration). You told the user upfront that they should still be able to use the existing OWA hyperlink and will get a page reminding them that their mailbox has migrated to Exchange Online and bookmark outlook.office365.com instead.

But instead, the user is presented with this page with a sad face instead:

The error message is:

We could not find a mailbox for this user. Either this recipient has not been configured with a user mailbox or does not have a license assigned. Please contact your helpdesk for further assistance.

X-OWA-Error: Microsoft.Exchange.Clients.Owa2.Server.Core.OwaUserHasNoMailboxAndNotLicenseAssignedException

Of course you have assigned Exchange Online licenses (or E3), and the mailbox has obviously moved to Exchange Online.

The resolution is rather simple but rarely documented.

Clear your browser cache, close the browser and login again.

Boom! The error goes away and the correct page showing the correct URL to be bookmarked.

Outlook.exe Lync.exe (and others) & nVidia GPU

So I have been noticing that for some reason, some Microsoft Office apps is starting to use my nVidia dGPU, even though I have set it to use integrated graphics using the nVidia Control Panel app.

I would see the following in my tray:

The only way for me to get rid of them is to disable my nVidia dGPU from device manager.

Until I stumbled onto this link:

http://www.slipstick.com/outlook/2013/outlook-2013-hangs-due-hardware-acceleration/

So I followed the article and turn off hardware graphics acceleration in Outlook 2016, and even without restarting Outlook, all the Microsoft Office apps stopped using the nVidia GPU:

So hopefully this helps someone :)

Exchange Online In-Place Archive not showing up in Outlook Web App

Ever had the problem when you have enabled the user's mailbox with In-Place Archive (a.k.a. Hosted Archive or Archive Mailbox), but yet it doesn't show up in OWA?

And you have tried to enable it for a hybrid mailbox, as well as a cloud only mailbox and both has the same behaviour?

The fix for me was a simple one - just clear your browser cache - for some reason that solved the problem for me.

Exchange Hybrid Free/Busy - Fails after running HCW to add more domains

So you have decided to run HCW again to include additional domains that you have skipped in the initial setup.

And immediately, you notice that free/busy query from Exchange Online to On Premises have started to fail again.

If you have already fixed it from my previous post, why is this happening again?

Firstly, run the following command from Exchange Online PowerShell:

Test-OrganizationRelationship -UserIdentity onPremiseMailbox@company.com -Identity “O365 to On-premises 6633cadc-0124-4111-2a22-e51f8853d1c5” -Verbose

Note that it will fail at STEP 4:

STEP 4: Getting organization relationship settings from remote partner...

RESULT: Unable to retrieve organization relationships from remote organization.
RESULT: Error.

But if you look back at STEP 3 - you will notice that the target URL is probably showing the new domain that you just added:

STEP 3: Requesting delegation token from the STS...

RESULT: Success.

Retrieved token for target https://autodiscover.newcompany.com/autodiscover/autodiscover.svc/WSSecurity for offer Name=MSExchange

.Autodiscover,Duration=28800(secs)

So what's the problem here? Most likely, this is used as a secondary email address and you haven't bothered to configure autodiscover for it.

To confirm this, run the following command from Exchange Online PowerShell:

Get-OrganizationRelationship | FL

Check out the "TargetAutodiscoverEpr" field, it is probably pointing to https://autodiscover.newcompany.com/autodiscover/autodiscover.svc/WSSecurity, instead of https://autodiscover.company.com/autodiscover/autodiscover.svc/WSSecurity

To solve the problem, either configure autodiscover for that domain (add it in public DNS, and update your TMG rules + add the SAN into your certificate), or just repoint it back to the correct autodiscover URL.

This can be done by executing the following command from Exchange Online PowerShell:

Get-OrganizationRelationship | Set-OrganizationRelationship -TargetAutodiscoverEpr https://autodiscover.company.com/autodiscover/autodiscover.svc/WSSecurity

Exchange Online - Mailbox Move Back On Premises Error

So you are trying to move a mailbox from Exchange Online back to your on premises Exchange Server and received the following error:

Error: MigrationTransientException: The call to ‎'https://hybridserver.company.com/EWS/mrsproxy.svc wstcorpcas01.wilson.com ‎(14.3.227.0 caps:05FFFF)‎‎' failed. Error details: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults ‎(either from ServiceBehaviorAttribute or from the configuration behavior)‎ on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.. --> The call to ‎'https://remotewest.wilsongroupau.com/EWS/mrsproxy.svc wstcorpcas01.wilson.com ‎(14.3.227.0 caps:05FFFF)‎‎' failed. Error details: The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults ‎(either from ServiceBehaviorAttribute or from the configuration behavior)‎ on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs.. --> The server was unable to process the request due to an internal error. For more information about the error, either turn on IncludeExceptionDetailInFaults ‎(either from ServiceBehaviorAttribute or from the configuration behavior)‎ on the server in order to send the exception information back to the client, or turn on tracing as per the Microsoft .NET Framework 3.0 SDK documentation and inspect the server trace logs. 


Looks horrifying right? You have probably tried to use different credentials, created another Migration Endpoint object in Exchange Online, all without avail?

Also you would be scratching your head because you were able to move mailboxes to Exchange Online using the same MRSProxy without issues,

This is probably due to the fact that you have entered the database name wrong:

You probably have databases in a DAG, and when you copied the database name, it ended up something like "database name\server name".

The fact that database names are unique in an Exchange organisation, there is no need to specify the server name.

So what you need to do is enter "database name" into the Target Database field and your migration should be fine.

Office 365 - Exchange Online - Free/Busy Query from Exchange Online Mailbox to On Premises Exchange Fails

This topic is quite a common one, but in my case, the resolution is not.

So let's start with the environment:

• Exchange 2010 SP3 RU12
• TMG 2010 
• HCW v3

Here is the problem: Exchange Online users cannot get free/busy information of users still on premise Exchange. The other way works fine, i.e. Exchange 2010 users can see free/busy information of Exchange Online mailbox users.

First and foremost, you should run through the following tool and checking everything is in place:

https://support.microsoft.com/en-us/help/10092/troubleshooting-free-busy-issues-in-exchange-hybrid-environment

It is a very comprehensive tool, and make sure you don't skip any steps.

In my case, everything checks out in that tool. Even running Office 365 Free/Busy test from Microsoft RCA also returns free/busy data from on premise user:

And the result would be successful, and returns the free/busy data for the on premise user:

As part of the troubleshooting process, you would run the following PowerShell command from Exchange Online:

Test-OrganizationRelationship -UserIdentity onPremMailbox@company.com  -Identity “O365 to On-premises

- 668sscac-01as-41s1-sd21-e5sslsh3d1c5” -Verbose

And the result would be:

STEP 5: Getting organization relationship setting from remote partner…

RESULT: Unable to retrieve organization relationships from remote organization.

RESULT: Error.

LAST STEP: Writing results...

And that's your first indication that something is broken.

If you dig into your Exchange CAS server's IIS log, and search for "testorg", you will see the following entries:

2016-04-07 07:03:12 10.80.5.101 POST /autodiscover/autodiscover.svc - 443 - 10.30.5.47 TestOrganizationRelationship/1.1 200 0 0 109

2016-04-07 07:03:12 10.80.5.101 POST /autodiscover/autodiscover.svc/WSSecurity - 443 - 10.80.5.47 TestOrganizationRelationship/1.1 500 0 0 0

By running the "Test-OrganizationRelationship" PowerShell command, it generates a test against the on premise Exchange server, and although when accessing "/autodiscover/autodiscover.svc" worked (as indicated by HTTP 200 code), but when accessing "/autodiscover/autodiscover.svc/WSSecurity", HTTP error code 500 (internal server error) is record.

OK, we are getting somewhere here. Why is /WSSecurity not accessible?

Let's check our WSSecurity settings on all CAS servers. Go to Exchange Management Shell, run the following commands:

Get-AutodiscoverVirtualDirectory -server | fl *wss*

Get-WebServicesVirtualDirectory -server |  fl *wss*

Notice that the result shows that WSSecurityAuthentication is already set to $true. So what now?

Well, we fixed our problem by setting the flag to $true again.

I know it sounds counter-productive, but apparently setting the flag does something at the backend and actually fixes the problem. 

So execute the following commands from Exchange Management Shell (on premise Exchange):

Get-AutodiscoverVirtualDirectory -server | Set-AutodiscoverVirtualDirectory -WSSecurityAuthentication $true

Get-WebServicesVirtualDirectory -server | Set-WebServicesVirtualDirectory -WSSecurityAuthentication $true

Next, either do a IISReset or just recycle the following AppPools from IIS Manager:

• MSExchangeAutodiscoverAppPool
• MSExchangeServicesAppPool

Voilà! Problem fixed. Run "Test-OrganizationRelationship" from Exchange Online PowerShell and it would work now. And now if you do the free/busy test, it should work.

This took 2 weeks to troubleshoot with 2 different Microsoft engineers, so hopefully this will help someone.

Lync Hybrid, or Exchange Hybrid with hosted UM - CS Static Route is not supported

Learnt this the hard way from two different clients.

Basically, when you need to have Lync Hybrid setup with Skype for Business Online ("SfBO" - same below), or when you are doing Exchange Hybrid with Exchange Online in an environment where there is already Lync setup with Unified Messaging, you have to make sure that there are no CSStaticRoute that exists, or else co-existence will fail.

Symptoms include:

• Lync Hybrid only: On premise Lync users cannot initiate IM with migrated SfBO user
• Exchange Hybrid with Unified Messaging: When calling the user's extension number, the call is directed somewhere else and not to the user's voicemail

This all boils down to the fact that when SharedAddressSpace is configured in Lync on premise with SfBO, CSStaticRoutes are no longer supported, and have to be deleted.

To confirm that you have a static route, run the following from Lync Management Shell:

Get-CsStaticRoutingConfiguration -identity global | Select-Object -ExpandProperty Route

The quickest way to fix this is to issue the following command to delete all static routes:

Set-csstaticroutingconfiguration -identity global -route $null

Enable-CsTopology

Wait for a few minutes and the problem will resolve itself.

OK, you might ask what are the effects of deleting all CSStaticRoutes - it could range from breaking your Polycom RMX integration with Lync to breaking a PSTN conferencing solution.

Unfortunately I have no advice on how to get around with this, other than paying a support ticket to Microsoft and get them to work with the third party vendors.

I was lucky because the customer no longer wants to use the RMX integration, and Polycom RMX integration does not work with Skype for Business Online anyway.

Hope this helps someone.

Determine the Azure AD Connect Installation File Version

Sometimes you want to use an older AADConnect installation file for some reason (usually due to a broken update), and you would want to know the version *before* installing it.

The easiest way to find out is to use 7-Zip to open up the MSI file, expand media1.cab file, and extract the file "Microsoft_Azure_ActiveDirectory_Synchronization_Setup_dll".

Rename it to "Microsoft_Azure_ActiveDirectory_Synchronization_Setup_dll.dll" and right click on the file, Properties and then Details tab:

In my case, it's version 1.0.9131, released in December 2015.

You can get the full version history for Azure AD Connect here:

https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnect-version-history/

Bonus tip! To manually force a sync using AADConnect 1.1, run the following PowerShell cmdlets:

Full Sync: 

Start-ADSyncSyncCycle -PolicyType Initial

Delta Sync:

Start-ADSyncSyncCycle -PolicyType Delta

Source: https://azure.microsoft.com/en-us/documentation/articles/active-directory-aadconnectsync-feature-scheduler/

Office 365: Maximum Number of Unverified Domains

Apparently there is a limit of how many unverified domains that you can have within an Office 365 subscription, and the magic number (as of 1 March 2016) is:

55

When you add more than 55 domains using PowerShell, you get the following error message:

Number of unverified domains exceeded.
Your account has too many unverified domains. Verify or delete one of your unverified domains, and then add the new domain.

The following article talks about the error, but does not mention the limit:

https://support.microsoft.com/en-us/kb/2279117

This article mentions more errors when adding domains into Office 365:

https://support.microsoft.com/en-us/kb/2762161

TMG 2010 - Error when importing configuration

Before we start, please read the large disclaimer:

I do not know what is the implication of performing these steps on a production TMG 2010 server/array, so please make sure you backup everything before doing this!

OK, back to business.

Have you every tried to restore a TMG backup (right cick on Array/Server > Import (Restore)) and received the following error message?

Error: 0xc0040411 - The file cannot be imported because the array is of version 2010SP2 in the exported file and version 2008 in the stored configuration.

You have already done the following with no avail:

• Checked that the patch level is the same from the XML file and the destination TMG 2010 server
• Make sure that you have chosen "Overwrite (restore)" option
• Untick "import server-specific information"

There is one more thing you can try. You can tweak the following lines in the XML file, and lower the version number. For my case, I changed "4" to "2" and the import worked, e.g:

Again, I am not sure what implication of lowering the CompatibilityVersion number, and I urge you to test it out before going production. Hopefully this will help someone in the future.