Wednesday, October 25, 2017

Azure Information Protection client getting wrong policies

Hi all,

While preparing for the Azure Information Protection demo, I noticed that the Azure IP client is "stuck" to my production Azure tenant, and will not download the configured policy in my demo tenant, I have done the following to no avail:


  1. Sign out from Office 365 ProPlus apps,
  2. Delete the registry keys under HKEY_CURRENT_USER\Software\Classes\Local Settings\Software\Microsoft\MSIPC\
  3. Reinstalled Azure IP client

None of which seem to have worked. Then I followed everything on https://docs.microsoft.com/en-us/information-protection/rms-client/client-admin-guide and the bit that got it working was:

From an Office application: On the Home tab, in the Protection group, select Protect, and then select Help and Feedback.





Click on Reset Settings -  signs out the user, deletes the currently downloaded Azure Information Protection policy, and resets the user settings for the Azure Rights Management service.

Right after restarting the Office application, you may or may not get prompted to sign into the Azure IP service - depending on your single sign on scenario. Right after that, the correct policies should be downloaded.

Friday, June 30, 2017

AAD Connect (1.1.524.0 and above) and mS-DS-ConsistencyGuid Permissions

Starting from AAD Connect 1.1.524.0 (May 2017) and above, the tool will automatically configure itself to use mS-DS-ConsistencyGuid as the sourceAnchor.

There are a few gaps in the official documentation (https://docs.microsoft.com/en-us/azure/active-directory/connect/active-directory-aadconnect-design-concepts#using-msds-consistencyguid-as-sourceanchor) and some blog posts out there:


  1. The correct attribute is mS-DS-ConsistencyGuid. Microsoft's official documentation is consistently having the typo "mSDS-ConsistencyGuid" - with the missing dash,
  2. You will need to delegate your custom service account to READ + WRITE to mS-DS-ConsistencyGuid. May documentation mentions WRITE but that is not sufficient,
  3. You may not be able to use AD Users and Computers to make the permission changes, depending on the operating system version of your domain controller.

The script that worked for me is:

$accountName = "domain\aad_account" #[this is the account that will be used by Azure AD Connect Sync to manage objects in the directory, this is an account in the form of AAD_number].
$ForestDN = "DC=domain,DC=com"
$cmd = "dsacls '$ForestDN' /I:S /G '`"$accountName`":RPWP;ms-ds-consistencyGuid;user'"
Invoke-Expression $cmd

Fix: Note the "RPWP" permissions. RP means read permission, and WP means write permission. Both are required for this feature to work, or else you will be met with the dreaded sync error messages in AAD Connect.


Tuesday, May 09, 2017

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

Friday, April 28, 2017

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


Thursday, April 20, 2017

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.