![]() Both the ingestion of the ADMX template and configuration of the required settings has to be done using a custom policy. It is also possible to ingest your own ADMX templates via Intune policy to configure settings for 3 rd party apps such as Google Chrome, Adobe Acrobat, etc. The complete list of ADMX-backed policies supported by Policy CSP is documented here: In addition to the settings available natively via Administrative Templates, you can also configure other settings via custom policy in Intune. The ADMX-backed policy is the underlying mechanism used by the Administrative Templates configuration profile template in Intune. I won’t go into the full details of ADMX-backed policy, if you want more insights into this then there is some great documentation on : However, there is also a way of creating the required registry keys and values via MDM policy thanks to ADMX-backed policy support ?. Using this method you could deploy a PowerShell script via Intune (user context) without having to worry about whether the user will have network connectivity to the on-premises network at the time when the script is executed on the client. If you are happy using PowerShell to manage the drive mappings then you could just create the appropriate registry keys and values using PowerShell. Note: There are some reports of network drive mappings failing since Windand adding setting the ProviderFlags registry value (set to 1) seems to resolve the issue. In addition, the ProviderFlags value should be set to either 0 or 1 depending on whether the remote path refers to a DFS root. The RemotePath value needs to be set to the correct remote path (UNC) for each drive. If the current user credentials are used then the value will be blank.Īll but two registry keys are the same for each mapped drive. The username used to connect to the share. For the Microsoft LanMan Provider the value will be 0x20000. The name of the network provider being used to connect to the network drive. If the RemotePath refers to a DFS root then the value is set to 1, otherwise set to 0. Indicates whether the RemotePath refers to a DFS root. If it is an alternative credential and the password has not been saved the value will be 1. Indicates whether the drive needs to be connected immediately at sign-in. If the mapped drive credential is the same as that of the logged on user or the credentials have been saved the value will be 4. The type of connection – for drive redirection the value will be 1 and if it is print redirection the value will be 2. Registry settings for network drive mappings Value Name ![]() There is a subkey for each mapped drive with a number of registry values within each key. Network drive mappings are stored in the HKCU\Network registry hive. This is particularly useful in a scenario where users will enroll devices on the internet without any connectivity to the on-premises network or with a VPN connection that may not be available immediately after enrolment. Understanding this then opens up other mechanisms to configure the mapped drives without any dependency on network connectivity to the remote path. It is possible to configure network drive mappings by simply creating the required registry keys/values. ![]() This is so that the drive mappings can be rebuilt at each user sign-in. When a network drive mapping is marked as persistent the configuration is stored in the registry. Ensure mapped drives switch from “offline” to “online” when connectivity to the remote path is available.Create mapped network drives without requiring network connectivity to the remote path.Easily change/remove mappings without having to edit/re-deploy scripts.Control assignment of drive mappings via Azure AD groups.Configure the drive mappings directly in Intune.The main requirements I had when I developed this solution were: Yes… network drive mappings without PowerShell?. In this post, I am going to share another way of mapping drives on Intune-managed Windows 10 devices without using anything other than MDM policy. These solutions typically use a combination of PowerShell, Scheduled Tasks, etc. There isn’t any native support for doing this within Intune today although there are some great alternative solutions already documented by some MVPs and members of the MEM community. Apart from the ability to configure preferences that the user can override/customize it also has some other useful features such as network drive mappings. One of the current challenges when moving from a group policy to MDM with Intune is the lack of support for group policy preferences (GPP).
0 Comments
Leave a Reply. |