Microsoft Intune – Things to remember before you use new Azure integrated Intune

As you may already know that Microsoft decided and moved from Classic Intune to Azure integrated Intune.  There are few things that needs to considered before you decide to use Azure integrated Intune for patch management.

  • The app groups that are created in Classic intune are being migrated to Azure integrated Intune.  These groups cannot be used in Classic intune anymore.  If you would like to patch the workstations with the existing group or create a new groups, it wont work – Microsoft acknowledged this as bug and awaiting resolution (This has been resolved now)
  • If there is a policy that exists in the Classic portal and you are using Azure integrated intune, and has a software update ring, then there might be a policy conflict.  Make sure the Classic Intune are removed.
  • Classic Intune can only manage the devices using Intune management agent.  Azure integrated Intune can manage the devices only if the device is enrolled as Mobile Device.  If the agent is present in the workstations, it cant be enrolled as mobile device.  So first thing you should do is to remove the Agent.
  • If the Agent is present in the workstation it cant be enrolled to new Azure integrated Intune.  You have to uninstall the agent, you can use  This will create a Schedule Tasks.  It may take about 5 to 10 mins.  It uses ProvisioningUtil.exe located under C:\Program Files\Microsoft\OnlineManagement\Common.  If you have custom installation path or if the exe doesn’t exist, then you might need to install the Agent again and run this script again.
  • If you are planning to migrate to Azure integrated Intune from Classic Intune, make sure the device is not listed in the Classic portal.  If the device is visible, then before enrolling, make sure the workstation entry is removed from the Classic portal.  Sometimes you may see entries in both the portal, In that case, you have to remove the device from both the portal, and re-enroll.
  • Finally, version upgrade of windows 10 is not straight forward.

Hope this helps


Spectre – Vulnerabilities

Recently Google Project Zero team has identified a vulnerabilities on CPU that is affecting all AMD, Intel and ARM Processors.

The variants of the issue identified so far,

Variant 1: bounds check bypass (CVE-2017-5753)
Variant 2: branch target injection (CVE-2017-5715)
Variant 3: rogue data cache load (CVE-2017-5754)

The entire Azure / Office 365 platform from Microsoft is being patched and rebooted as a matter of priority to resolve this problem.  You might have already got notification to do a redeploy at your convenience or MS would have forced it last week.

To take care of the on-prem infrastructure, MS has released patches

No patches will be available for Windows XP, Vista, 2000, 2003 etc.

These patches only mitigate the exposure of vulnerability but not resolve.  You MUST update your infrastructure as soon as possible and also check for any manufacture update like BIOS or driver updates

*Google Chrome, IE, Firefox also got some updates last week to handle this vulnerabilities.

Hope this information was useful.


Blocking Third Party application to access Office 365

When you have your users on office 365, they tend to use integrate their account with third party cloud applications.

The advantage and dis-advantage of using office 365 is that it integrates seamlessly with the third-part cloud application.

One such application that i came across is that CloudHQ.  It is very good product.  When you work with different client, and their respective application, CloudHQ, helps get those information to one place.

For example, If a user has a office 365 mailbox and a gmail account.  He can extract all the emails from office 365 and transfer it to gmail account.

All you have to do is just authenticate authroize CloudHQ to use your office 365 account.

CloudHQ can do lot more than what i just described.

To some organization, they don’t want their user to take the corporate data to external application which is not allowed.

How a user can sign-up to these applications (I user CloudHQ as an example)

Go to the website


Sign-up using the office 365 account


Logon screen to office 365


Authorize CloudHQ to your office365 account,


As soon as it is done, admin can see this application under Enterprise application list


Right now, this user has authorized CloudHq to access the office365.  From CloudHQ, you can authorize your personal email account, such as gmail, as the destination to copy the emails.

To avoid this,

You might wonder if disable active sync or other features may allow you to control access of the users – NOPE.

Even if you disable EWS, user will be able to authorize the application to access their office 365 account.

The only way to control this is by setting the restriction in Azure portal.  You can block all the application except few MS application or which ever way works for you.


Hope this was useful.


X-Microsoft-Exchange-Diagnostics-untrusted header – (NDR) Message header is too large – (Resolved)

Note : This issue has been fixed by Microsoft.  This article is just for an information

If your office 365 is setup to amend signatures to your email that are going out to external domains or attaching disclaimers to the email, then

There is existing issue.

The size of the message header grows drastically if you have this setup.  If you look at the messaging header, the content might be filled up like below,

X-Microsoft-Exchange-Diagnostics-untrusted: 1;VI1PR0602MB3232;7:eitiAZyhSkfzWdu2wx4WYDDsg97GybOhP52ygjEEopTGZOnqE44bl













Because of the large size of the message header, the recipient domain may reject your email saying it is not complaint or message header size is too large.

To fix the problem,

You can remove the X-Microsoft-Exchange-Diagnostics-untrusted header using transport rule,


Or Simply wait until Microsoft fix it.


ADConnect Sync Issue – Resource/Active forest topology

Recently i’ve encountered an issue with the AD connect. I thought it is worth sharing with others.


There are 2 forest

1. Forest A and Forest B
2. Exchange is installed on Forest A
4. Forest B users mailbox are on Exchange server which is in the same forest
3. Forest A users mailboxes are on Exchange server which is in the forest B

The typical setup of the organization is below



For office 365 migration, AD Connect has 3 connectors

Connector for Forest B – Syncs the user attributes of forest A
Connector for Forest A – Sycns the AD object attributes of Forest A
Connector for Office 365 – Projects the object and their attributes to Azure AD

Forest B users mailboxes are migrated to office 365, Forest A users mailboxes are still on prem.

The reason for projecting the forest A object to AD Azure is to make use of sharepoint online and eventually migrate them to office 365.


Ok, the issue here is that, one of user from forest A is assigned with share point but unable to login to it.


Sequence of steps that i tried to fix this eventually helped me understand

How AD Connect works.

1. Sharepoint license assinged correctly, and the sites are ok (with the help of sharepoint support i confirmed it is setup correctly comparing with the rest of them)
2. Searched the Forest A connector to see if the user AD attributes are projected – yes it does
3. Searched the Forest B connector to see if the mailbox attributes are projected – yes it does
4. The immutableID of the user object from AD Azure matches the base64 objectGuid of the AD object matches the Forest A (this proves that source anchor is from Forest A)

The catch is, Both the connectors are projecting assuming both are different object

How this supposed to work

1. the attributes of the user from Forest B called msExchMasterAccountSid is matched with the objectGuid attribute of the user in Forest A
2. The AD object on Forest A must be disabled
3. The metaverse should combine the AD attributes from Forest A and Exchange attributes from Forest B and project it to AD Azure


1. Move the user object to non-sync OU on both the forest A & B
2. force the Delta synchronization on all 3 connectors
3. Move the user object in Forest A to syncing OU
4. Run the full synchronization on Connect for forest A, Connector for Office 365
5. Move the user object n Forest B to Syncing OU
6. Run the full synchronization on Connect for forest B

This resolved the problem

But what difference does it make?

Lesson learnt is,

When we create the connector it automatically takes the first priority, so Forest B was project disable object. The second connector created was Forest A, it took the second priority.
For some reason the metaverse cannot combine the disabled Forest B (Exchange attributes) and Forest A ( AD Attributes).
By manually syncing one after the other, the issue was resolved.

But wait, should i do it everytime when new user is created – NO

You can change the priority by yourself using “Rule Editor” which gets installed along with the AD Connect. Keep the priority of the the active forest at the top and the resource forest first to the bottom.

Hope this was useful

Case study for Office 365 migration – Part2

So, in my previous post i have discussed about the existing setup and the challenges to address the problem.

Here, i’m going to discuss about the proposed architecture and how it is going to address the challenges.

new architecture

  • Before starting the new setup, the mailbox that was created for ABC users on UK.XYZ domains are removed.  The synchronizations between mailboxes are removed.
    • Reason : This is to make sure there is no duplicate user mailbox residing on either side of the forest.
  • UK.XYZ exchange and ABC exchange connected to each other (Quest migration manager).
    • Reason : The mailboxes from UK.XYZ to ABC exchange to be migrated and it needs to be associated with the AD Account associated with each users AD account.
  • AAD Connect is installed on ABC.COM to synchronize to the AD Azure.
    • Reason : This is to make sure only ABC should be the primary domain, eventually the other domains acts as a resource domain for other applications and slowly decommissioned
  • New domain called and used as upn for both ABC and domains
    • Reason : This is to have a common authentication.  So users can use this as a domain to authenticate themselves to office 365
  • Federation trust and connectors on both the and exchange servers
    • Reason : When users are connected in their respective domains, they should be able to resolve other users name, share calendar and route autodiscovery service seamlessly
  • New exchange CAS server installed in and given exception to the CAS Array and a third party certificate installed which just one domain
    • Reason : This is to make sure, this server act as a EWS/MRS endpoint.  The users don’t connect to this server by giving exception in the CAS array.
  • Cloud identity management introduced to make sure it is does the authentication
    • Reason : No separate architecture required for ADFS.  This also enables the customer to use more cloud based solutions such as Box.
  • Remote mailbox has been created for every user mailbox which are migrated from to abc exchange server
    • Reason : When user connects to outlook, they should be redirected to Office 365 mailbox.  So no matter where the users their desktop, the outlook reaches office 365
  •  Users office 2010 has been upgraded to office 2013 or 2016
    • Reason : This helps to avoid additional autodiscover dns record.  Outlook 2013 or 2016 has that capabilities.  It tries traditional autodiscovery and finally reaches the office 365 automatically.
  • Both incoming and outgoing emails are filtered in domain.
    • Reason : This helps to maintain hygiene and plus maintain single infrastructure for email gateway.
  • A new cloud based solution for MDM is introduced.  All the user needs to re-configure their device.
    • Reason : Mobile iron and Okta apps gives a very good multi-factor authentication method.  It is very simple if a user know how to download an app and follow the on screen instruction

This case study may not be perfect solution but it is definitely worth a read.  If you have suggestions on how this could be made better, drop your comments.

Incase if you missed my Part – 1 


Exchange certificate – Best Practice

Having worked with different exchange environment, every since the release of Exchange 2007 use of certificate has been made compulsory. It should be either self-signed or third party certificate, that should have the domain names. The best practice is to use SAN certificate.

The things that i learnt during the certificate renewal or installing a new certficate,

1. Always use exchange powershell script or exchange console to import the certificate.

Reason: i have seen few admins prefer to use certificate console to import the certificate. when you install using certificate console, it may not reflect in the exchange console when you want to assign the services.

2. Always generate a CSR from Exchagne powershell or IIS service

Reason : When you create a CSR there will be a thumbprint associated with it. So when you complete the certificate installation for the request, certificate that you install should match the thumbprint

If you install a certificate that doesnt match the thumbprint, then you might see the installation successful but it wont show in exchange powershell nor in Console. But you can find the certificate visible in certificate console on that local computer

3. Always use a SAN certificate

Reason : As you may know that there are exchange services like ews, auto-discover and so on, you need to have certificate for each services. If you have single domain certificate, then it would be expensive and add more complication to the exchange setup

Case study for Office 365 migration – Part 1

Recently i worked on Exchange 2010 to Office 365 migration.  It is a complex environment, i had to customize too many things to be able to make this successful.  This post is to explain the challenges that i have faced and how i was able to get around the situation.  I’m not covering technical details of the migration process, but it is just a case study.

First let me tell you the existing architecture,

  • Parent company – ABC.COM
  • Child Company – XYZ.COM
  • Child domain of the child company is – UK.XYZ.COM (this is domain were Exchange environment is present)

The oragnization decision is to bring all the employees under one roof.  Atleast for now, to bring email systems to parent domain.

Existing setup is

architecture copy

  • Each users from UK.XYZ.COM have a separate AD account to access the ABC.COM resources.
  • Each users from UK.XYZ.COM are mapped to the corresponding AD account on ABC.COM
  • The password of UK.XYZ.COM users account and their corresponding AD account on the ABC.COM are sycned using Dell password sync.
  • Each users from ABC.COM have a mailbox on UK.XYZ.COM, and the email are forwarded to ABC.COM mailbox if any emails are sent.
  • If there is any email for UK.XYZ.COM coming in ABC.COM, it will be routed through the AD accounts created on ABC.COM

So, the environment is so complicated, and the job is to bring everyone under one roof when migrated to office 365.

I’m not going to explain technical details, rather I’m going to explain the challenges and how we overcome all that.

For any given architecture i feel that following should be the prime focus of an Architect,

  • Defining a Model like
    • Type of licensing
    • Identity management
  • Active Directory consideration
    • UPN identification
    • Domain trust consideration
    • attribute consideration and remediaton
    • Identification of OU to be synched
  • Exchange server consideration
    • Mailflow
    • Email domains
    • Autodicover & Exchange web services
    • Exchange certificate
    • Active sync solution/MDM
    • Message limits
    • Mailbox sizing
    • Public folder
    • Archiving and Journaling
    • SMTP relay setup
    • Third party integration
  • Network Consideration
    • Bandwidth & Utilization
    • DNS requirement
    • Internet proxies
    • Firewall ports consideration
  • End-user desktop considerations, like windows version, outlook version, anti-virus
  • Future expansion consideration

Out of the above said considerations, the challenges that needs to be addressed or discussed

Mailflow – Right now, there are 2 incoming gateway.  one for ABC.COM and one for XYZ.COM.  When we implement office 365, how this is going to affect.  How many hops an email had to travel?, How to address the email loop? and so on

Dirsync – Right the password is synced from XYZ.COM to ABC.COM DC’s through Dell password sync.  After Office 365 who is will be the authority for syching the password.  Is is ABC.COM only or Both ABC.COM and XYZ.COM? if it is single authority, then which domain should own it?

Domain name – Fortunately, both domain has a common name,  Can we use the same name for the user to authenticate themselves to Office 365? if they use the same @domain name, if so, how this can be federated for 2 domains?

Domain Trust – There is one way trust between XYZ.COM to ABC.COM.  Though the trust between 2 root domains are transitive, does that going to impact UPN?,

Auto-discover – Since both the domain have the same common name, after migration, how the users from each domain will reach Office365 mailbox from inside the network? External URL needs changes? or Outlook on the client machine needs to be upgraded (User have office 2010)

MDM – Users in both the domain users same MDM solution (mobile iron) but different infrastructure.  Does that need to be changed? or both the infrastructure should be integrated or redefine a new solution?

In my Part 2 post ill explain how to overcome this challenge and the resulting architecture


IE11 issue

Recently we have upgraded all the IE 9 to IE 11.  The testing went well but didn’t realize that we found an issue after implementation.


The certain group policy settings which are applied to IE9 are deprecated.  One of them is proxy settings.

We push the proxy settings through GPO, soon after the IE9 upgrade to IE11, the proxy settings stopped applying


So, to fix the problem, we need to have set of GPO settings that is applicable to IE11. There is a catch.

You need to have at least one windows 2012 server (member server) for creating and applying the policy.

There are 2 ways to fix it

  1. Find the list of registry changes that the GPO is going to make to the client system for IE 11 and create GPO registry preference
  2. Install a new windows 2012 member server and create the policy using that

Resolving Time sync issues

We have had lot of issues with Time sync on members servers.  If the time is not in sync with the domain controller, you may see issues but those errors and problem may not directly point to Time issues.


Once such scenario that I ran in to, in my environment, there are different time source,

  • My root domain is syncing with parent company
  • My primary child domain is syncing properly with root domain
  • DMZ, and resource domain time are syncing with Vmware, and external source.

To add more complication to the existing problem,

  • Partly my resource domain servers are in DMZ as well
  • I have windows 2000 and windows 2003 servers

The best thing about resolving the problem is that, I don’t have to restart the server after making the changes. So i can make changes immediately and restart the time service without any downtime


  • To prepare myself to resolve the problem is that, I need a report of all the servers which are not synching with the DC’s or domain.  The script from Time Sync report from member servers and create a .txt file called server.txt and add all the servers in your organization in the same path where you have this .ps1 folder
  • I need to segregate the list of servers based on their operating system
  • Then I need to find their location (DMZ, site) to identify the nearest DC that I can contact

Finally, I could sort about 200 computers which are not syncing with DC’s.  I tweaked the script and run the script to do a mass change.  Of course, windows 2000 and windows 20003 must be treated differently (fortunately I just had 10 servers of this nature, so I did it individually)

Note: I don’t own the script, i’m not responsible for the scripts if it malfunctions