Map different users additional network drives - Policy merge?

Question

Map different users additional network drives - Policy merge?

jkrgr0 opened this issue 2 years ago · comments

Hello,

I'm currently trying to implement your solution for one of our customer but I'm not sure how to manage different drive mappings for specific users.

Example:

All users needs the drives N:, O:\ and Z:\
User1 needs additionally drive W:\
User2 needs additionally drive W:\ and X:\

So my idea was to create three configuration profiles (N:\ O:\, Z:\ | W:\ | X:\) and assign the profiles to the specific user groups.
But with this approach it seems that I've created a conflict and not all drives are being mapped.

What would be the optimal approach for this?

Thanks!

Weatherlights · Answer 1 · Tue Mar 15 2022 16:11:54 GMT+0800 (China Standard Time)

Hey

Sadly that is not possible in the way the ADMX is designed. So you should create 3 policies with the following mappings:
N:\ O:, Z:
N, O, Z, W
N, O, Z, W, X

As an advantage you have additional flexibility in case you later need to change mappings for a specific group but of course it is a little redundant.

But you can merge with the other policy settings (so for example the Enabled setting or the Interval).

Best regards
Hauke

Janek · Answer 2 · Tue Mar 15 2022 16:33:15 GMT+0800 (China Standard Time)

Hi

Okay, thanks.

If the ADMX is designed like this (for each drive a specific policy) we would be able to split the drive mappings in multiple configuration policies without the risk of conflict.

Any chances of an implementation like this?

Weatherlights · Answer 3 · Tue Mar 15 2022 16:40:54 GMT+0800 (China Standard Time)

Hey

Yea I may consider it :). I would need to implement side-by-side with the old mechanism to ensure that versions configured the other way still need to work :).

Best
Hauke

Janek · Answer 4 · Tue Mar 15 2022 16:54:10 GMT+0800 (China Standard Time)

That would be nice!
This would also increase the visibility of the configured drive mappings in the profile itself.

Weatherlights · Answer 5 · Tue Oct 11 2022 15:12:08 GMT+0800 (China Standard Time)

Hey Sadly that is not possible since you can only provide one set of drives with a policy (This is by design of how the ADMX templates work). So you should create 3 policies with the following mappings: N:\ O:\, Z:\ N, O, Z, W N, O, Z, W, X As an advantage you have additional flexibility in case you later need to change mappings for a specific group but of course it is a little redundant. Best Hauke

carlitocabana · Answer 6 · Sat Dec 24 2022 02:19:17 GMT+0800 (China Standard Time)

Hello,

I'm currently trying to implement your solution for one of our customer but I'm not sure how to manage different drive mappings for specific users.

Example:

All users needs the drives N:, O:\ and Z:\

User1 needs additionally drive W:\

User2 needs additionally drive W:\ and X:\

So my idea was to create three configuration profiles (N:\ O:, Z:\ | W:\ | X:) and assign the profiles to the specific user groups. But with this approach it seems that I've created a conflict and not all drives are being mapped.

What would be the optimal approach for this?

Thanks!

We also need this. We have multiple shares assigned to multiple groups. So for exact mappings we literally need a lot of profiles. I'm curious if we edit the ADMX and add a second policy name with a new name <policy name="NetworkDriveMappings2" and a new regkey will this work or does the app/agent doesn't support this? What is necessary to make this work :-) Virtual beer ?

rnollen · Answer 7 · Thu Jan 12 2023 17:57:56 GMT+0800 (China Standard Time)

We where able to do this, where we can deploy it to different user groups. It works OK. So maybe the developer can consider it. What we did. Deploy the Store App. Ingest the ADMX, but in the OMA Uri policy we have not set the NetworkDriveMappings value, only the other ones. Now, on a reference PC in local registry of HKCU\Software\Policies\Weatherlights folder (where the drive letters are set for the app) we have created all possible Drive mappings with Dummy information in it. So FDrive with value \networkpath<Share>, GDrive with \networkpath<share> and then the whole alphabet we have placed in the registry. Next step is to export this location to a Reg File. Using Call4Cloud Reg to ADMX tool we have converted this Registry file to ADMX. Using Intune and Import this ADMX File. Now we can (graphically) create seperate Device Config ADMX policies with one Drive mapping is set and deploy this to a usergroup. So basically we do not set the Oma Uri but we hardcode the mappings into the Registry for this Tool using the ADMX. This we apply for a usergroup. The benefit to use ADMX in stead of a scripts, is that we are now also able to retract current drive mappings for users when the mapping is not necessary anymore; otherwise you would need different scripts for this. we found this easier to use.