First off, I want to promise you that this article is not clickbait. In short, I'm here to say that what the current documentation as of 8.1.2017 states is factually correct but it is omitting something rather large for those performing a switchover. And again - I know this is a Service Manager blog so why am I bothering to talk about SCCM/InTune? As always, I'll get there.
Per the opening lines of Microsoft's document you can change your MDM Authority without having to re-enroll devices. GAME ON! If you are standalone or hybrid and looking to switch to the other, this is some pretty fantastic news. But if you're a SCSM Mercenary in your own right, you're probably (hopefully) switching to hybrid because you want all of that awesome mobile device data to get pulled into SCCM, and in turn SCSM. I can't say I blame you. So here's the two biggest gotchas and entire point of this post that could introduce some unease you when converting from Intune standalone, to SCCM/InTune hybrid. You can jump to point #2 if you want to get straight to the landmine and point of this article.
1. Apple Push Notification Certificates (APN)
This process is not necessarily difficult, but when you read Microsoft's documentation closely it may startle you a bit if you think on it. In short - when the switchover is performed you need get the same APN that was used on InTune standalone. Because until you do this, you can't enroll new devices/potentially manage your current devices.
Again - it sounds a little terrifying. So you may think...
Well I'll just request the APN before performing the switchover. That way the APN is already in place and there isn't a single second of non-managed iOS devices.
There is only one problem, SCCM will not let you and doesn't provide any warnings/popups to tell you otherwise. If you attempt to perform the APN request before switching from standalone to hybrid, you'll get the InTune sign-in prompt to log into your tenant. However the second you sign in, this new dialogue box goes solid white and nothing happens. It will just hang out at this white screen indefinitely.
It's with this said, you may get cold feet thinking...
If it doesn't work now, how do I know it will work after the switchover? I suddenly feel very uneasy about this. I can't risk losing management of my iOS devices!
Fret not because the directions per Microsoft's documentation should absolutely be followed in order. So yes, I am in fact telling you to read the manual.
Lesson Learned: You have to perform the switchover from standalone to hybrid, then request the APN per the instructions. If you attempt to grab the APN first, you get a solid white screen after the login. Doing it in the correct order takes less than 4 and half minutes (unless you can click faster than me) with no impact to the management of your iOS devices.
2. Device Groups and Collections (the real "gotcha")
As Microsoft documentation explicitly states on several occasions, you should re-create policies as soon as possible after the conversion. But here we go again. Order of operations. Does it matter? The good news here is that no it does not!
Create new SCCM Device Collections with names that mirror the Group names you've setup on InTune. Create Configuration Items/Baselines and point them at your new collections mirroring the way you've configured your policies within the InTune portal. This way when devices get thrown into those groups they immediately receive their new policy from SCCM and drop the one from InTune. You're in the home stretch! Time to make that switchover -
Wait a second...how do I get devices from their InTune Groups to their new Device Collections in SCCM?
BOOM! Well as long you don't step on this landmine everything will be fine. During the conversion process, there is absolutely nothing that InTune nor SCCM do to ensure that devices move from an InTune group to a SCCM Device Collection. Everything will in fact get dropped into the out of box "All Mobile Devices" Device Collection. This said, the onus falls on you the customer to shuffle the devices into their new device categories/collections so as to minimize lax policy coverage.
But what about Device Categories? I had to re-create those before the switchover. Can't I leverage that somehow to get out of this situation?
Unfortunatley, no. You created the Device Categories. So any Device Categories currently on InTune and/or associated with devices unfortunately mean absolutely nothing in this conversion! You probably even found this article from System Center Dudes that tells you how to configure new Device Categories within SCCM and while it is 100% correct it is only addressing new devices going forward post switchover. Which means once they come down, you'll have to re-categorize them!
So how can we right this? You've spent all this time meticulously recreating all of your InTune rules in SCCM. How can we ensure that we continue to deliver policy as soon as we can post-switchover? Hopefully the answer won't surprise you - PowerShell.
Lesson Learned: Handling InTune Groups and SCCM Device Collections is a bit disjointed
So now having realized that we still have to do some shuffling of devices once they arrive in SCCM, first we'll export a list of devices from an InTune group. Just head over to the InTune portal, go to a Device Group, view its members, and export to CSV. Repeat this process for all the groups you have.
After the switchover occurs, it will take several hours before all of your InTune devices are registered within SCCM. But as they arrive, we can keep sorting them with PowerShell. The script below will read the Name column of the CSV, find the corresponding device in SCCM, and then add it to the Collection of your choosing where Configuration Items/Baselines are being applied. What we're taking advantage of here, is that the InTune portal uses the identical Name property that we'll eventually see within SCCM. You'll want to probably get this script running on some kind of regular interval if any lax policy enforcement concerns you. Otherwise, per Microsoft document you'll have 7 days to get everything setup correctly before the InTune rules get dropped and SCCM truly takes over.
# skip the column header
$devices = get-content "path to intune csv export" | select -skip 1 | ConvertFrom-Csv
$sccmCollection = Get-CMDeviceCollection -name "collection name"
foreach ($device in $devices)
{
Add-CMDeviceCollectionDirectMembershipRule -CollectionID $sccmCollection -resourceid $(Get-CMDevice -Name $device.name).ResourceID
}
Once you've got the current devices setup the way you want, you're good to go! Then going forward, device management will be handled by the Device Categories you created in SCCM and dynamically associated with Device Collections. Thus addressing all new device enrollments.
Note: The alternative option at the time of this writing is manually assigning (one by one) the Device Category to each device as it appears. The downside of this approach is you constantly have to revisit the All Mobile Devices collection for new devices as they appear and categorize. Not to mention, that you do in fact have to do it one by one! There is currently no supported method in the GUI or PowerShell to mass set/foreach loop the Device Category. However, I suspect there is probably someway to address this on the SQL backend. You can read more about there on the TechNet discussion here.
Endgame - Service Manager
So once you've righted these wrongs and you've made the switchover, what does this have to do with SCSM? Well if you're syncing SCCM data into SCSM, you'll be happy to know that a Mobile Device class exists within SCSM and will become populated with this new wealth of data. Which means you can attach mobile devices to Incidents, Changes, Service Requests, etc. What's the even slightly larger payoff? Devices will sync their Primary User relationship! So now when navigating within SCSM, you can view not only the computers a user access, but you can see the relationship to their mobile devices as well.
With this new integration point, a new wealth of possibilities are unlocked for SCSM. Here's just a few examples:
- Service Requests on the self-service portal based on currently signed in user and their mobile devices
- Incident Requests on the self-service portal based on currently signed in user and their mobile devices
- Service Requests that initiate SCCM automation to lock, wipe, and reset devices
- Could be relevant to end users, analysts, or both
- Asset Management processes (if you're a Cireson customer, the possibilities here become even larger)
- Extend the SCCM Mobile Device class within SCSM and use SCO/SMA jobs to further populate more data from SCCM into SCSM
While getting all of these devices into SCSM stand to benefit your ITIL/Service Desk processes, it plays a much larger role in the name of Service Manager not just as a "ticketing tool" but a truly self-maintaining CMDB.
Go forth and automate!
