Here is a quick bit of advice: take your time when moving your CM-integrated Intune subscription to another CM site.

With that said, there are very viable situations as to why you may want to migrate from a CM 2012 R2 site to another CM site. For example, I was tasked with upgrading the OS of a client’s Primary Site Server from 2008 R2 to 2012 R2. Additionally, I was to relocate the site database (existing on another server) to the Primary Site Server, upgrading the instance from SQL Server 2008 R2 to 2014.

Sounds like a big ball of fun, right?

Well, I came to the conclusion that the easiest route would be to stand up a new server and migrate the environment to a new site. There were more factors involved (I did not particularly care for the way it had been configured in the first place), and this just seemed like the path of least resistance. And, I was right… that is, until it came to moving the Intune subscription.

I saved the Intune subscription move until last because I believed it would be relatively easy, straightforward, and we would have everything in place for as seamless of a transition as possible. Naturally, I was aware that users would have to re-enroll their devices, but with migrated collections, policies, etc., it seemed like a small price to pay for a much better environment.

Fast forward to the fun part.

After all was migrated over and healthy, I removed the subscription from the old environment. I then added it to the new site, and everything looked good with no errors when installing. I even revoked the Apple APN cert and generated a new certificate request. All looked good. Great, even. Best five minutes of my life. [enter implosion]

I noticed that, when I attempted to enroll a device, the Company Portal displayed some information from the previous portal configuration. Words that I KNOW I capitalized in the new configuration were not the same; it was evident to me. However, the enrollment procedure succeeded, which was odd.

I looked in the CM DB and never saw the device. I waited for hours and still, nothing. So, I unenrolled and tried again. I was able to successfully enroll the device, yet it would not appear in the database.

I removed the subscription, like any decent troubleshooter would do, and added it back. Same results. I then added it back to the old environment, enrolled a device, and lo and behold, it appeared! I checked the Management Authority in the Intune management portal, and it was set to Configuration Manager. Anyone who has set up CM integration with Intune knows that this is permanent and cannot be changed. But, does it need to be reset in the instance of a migration to a new site?

The short answer is… I’m still not clear.

Microsoft’s answer (when I got them on the phone; and, believe me, I’m telling the short version of this story) is that all devices must be “retired” from the old environment before moving the subscription. However, I know that we (Model) have lost a Site Server with an active Intune subscription, set up a brand new site (new site code), and added the subscription without any issues. Regardless, retiring every device was not an option at this point, as time was of the essence.

Microsoft decided to do a Management Authority reset (which, funny enough, was the very first thing that I suggested when I called, but that’s neither here nor there). After waiting another day for the “all clear”, I added the subscription again. Yet, once again, nothing was flowing.

Keeping the story short (again, trust me… this is the short version), the dmpdownloader.log kept populating with “Error: FastDownload Exception” and “service busy”. After looking deep into the dark of the log, I saw CM was associating the subscription to a thumbprint.

However, the thumbprint did not correspond with what was in the registry (HKLM:\SOFTWARE\Microsoft\SMS\SMS_DMP_CONNECTOR). I blacked out the key to protect the innocent. 🙂

Ok, good times. On a roll. So, now, why do they not match? Well, a quick check into the local certificate store and I see three different certs from SC_Online_Issuing! Certainly, these are from several attempts at adding the subscription.

I cracked one open and found the thumbprint that was in the registry. However, to keep things clean, I removed the subscription, deleted all certs, and started over from scratch. This time, as soon as I added the subscription, users began to sync to the cloud and policy was flowing!

Hopefully, you haven’t had to experience this type of pain if you have ever moved a subscription. Logic would tell you that it is simple (as it should be). However, if you are having issues that are similar, pay close attention to your local cert store, and feel free to message me with questions!