This week we were visiting a new customer with still some on-premise software and a lot of data. They asked our opinion on what we thought would the best way to transform into a modern workplace.
The first thing that probably will come to mind… go hybrid!!
Of course, you can configure your devices to use an autopilot white-glove hybrid azure ad join but what if you don’t want the cons of this kind of deployment? I guess the main disadvantage of using hybrid is you still need a line of sight to our on-premise domain controller (sometimes) and you are still stuck with some old group policy objects who can really mess-up your Intune settings.
For example: DisablePersonalDirchange will cause Onedrive kfm to stop working.
Not forgetting the fact, you must deal with all kinds of forgotten settings that were configured by someone else who is probably long gone? Of course, it’s best practice to configure the MDM wins over GP setting to make sure your Intune policies would win when you have a hybrid setup but beware it only works with conflicting policies.
After we were talking for some time, we knew in which phase of transforming to the modern workplace, the company was. It was obvious it would take some time to move all the data to onedrive/sharepoint/teams. When moving to MS365 cloud only you, will need to follow this simple rule.
Luckily the customer already decided to implement Azure ad connect to sync their identities to Microsoft 365. After your identity is synced to Microsoft 365 you will need to migrate your devices. (DBF –> Devices Before Files)
As said before, there are some disadvantages when you choose to implement azure ad hybrid. We advised the customer to skip the hybrid part, why you might ask?
Summing it up: When using azure ad connect you can still access your on-premise file shares from an azure ad joined device with SSO. Sometimes you can even use Windows Hello and still have SSO. So you need to try SSO first without Windows Hello, if it’s working enable it and test again. Otherwise, you may need to enable it:
Why would you create a more complex environment then is needed? Creating a fresh new start with no old existing issues is just great! Some examples from our point of view
-They already had a Remote desktop cluster. So, for now we could publish the legacy app as a remote app
-All existing thin clients needed to be replaced
-Their own personal documents and desktop could be moved to Onedrive
-We can install/push printers from Intune or migrate them to a cloud printer Solution.
-We can ditch the old AV and start using Microsoft Defender for endpoints.
-We can use the windows update for business instead of an old (not working) wsus server.
-We can access the data file shares which are not yet migrated to Sharepoint (of course we are going to migrate the existing data to sharepoint when all devices are ready)
But how are we going to map some old-fashioned drive letters without the use of powershell? I guess everyone has deployed Adminless and Applocker and of course you made sure your applocker policy will block powershell for the regular users.
In some older blogs I showed you the possibility to ingest some admx templates to configure some additional settings, so why not doing the same for the drive mappings?
The only thing you will need is the drive mapping admx file which you will find here:
First, we need to configure the CSP for the admx
OMA-URI: ./Device/Vendor/MSFT/Policy/ConfigOperations/ADMXInstall/DriveMapping/Policy/DriveMappingAdmx Data Type: String Value: content of the drivemapping.admx file
And of course, a separate csp for the drive mappings and itself
OMA-URI: ./user/Vendor/MSFT/Policy/Config/DriveMapping~Policy~DriveMapping/Drive_H Data Type: String Value: <enabled/> <data id="Drive_H_RemotePath" value="\\fileserver\fileshare"/>
While waiting for the custom made policy to apply, look at the registry to check if you already can find the ADMX policy.
As shown above, the admx drive mapping admx is installed without any problems and within a few minutes the drive mapping itself started showing up.
After logging of and logging on again, the drive mappings popped up and where ready for use.
If you have the possibility to replace all existing devices instead of enrolling the existing domain-joined devices into azure, is there still a need to join the new devices to your on-premise domain? With an azure ad join you can get sso to your onpremise domain even when using windows hello.
Please think twice before you go azure ad hybrid. Isn’t a simple azure ad joined device not enough? I love to hear your thoughts.
It’s great to see you can also map drive letters without the need for PowerShell. I guess there are no reasons left to block Powershell for end users.
It’s no discussion the data will need to be migrated soon, but Rome was not built in one day.