Syntax for Onedrive.admx edits - DefaultRootDir

Steel Contributor

In the Onedrive deployment guidance we're instructed to edit the Onedrive GPO template (Onedrive.admx) to insert specific values.

 

For example, replacing {INSERT YOUR TENANT'S GUID HERE} with our actual tenant GUID.

 

The GUID part is easy, but the next customization is replacing {INSERT YOUR CHOSEN PATH HERE} with the desired path for the DefaultRootDir, i.e. the path you want Onedrive to sync to locally when the user runs through the first time setup.

 

My notes from BRK3081 at Ignite show a recommendation to use "%userprofile%\Onedrive - CompanyName" or a %userprofile% path.

 

I've had lots of success with Onedrive deployment by not enforcing that DefaultRootDir in Onedrive.admx, and just enforcing the DisableCustomRoot option instead. So the desired outcome of Onedrive syncing to %userprofile% is met, because users can't select a different location.

 

But I've had no success with enforcing the DefaultRootDir via GPO. Any attempt to use variables like %userprofile%, or C:\Users\%username\etc, or any other variable, fail during user setup of Onedrive.

 

Example:

 

onedrive-setup-error.png

 

So my question is really, what values or syntax will work for {INSERT YOUR CHOSEN PATH HERE} in the DefaultRootDir config in Onedrive.admx?

47 Replies
Awesome, thanks Ronak - although I'll wait till Monday ;)

This sounds very promising. I'll have a look for the technical documentation so I can understand how to make best use of the templates.

Thanks!

I have trialled the new ADMX files that are included with the latest production client and have found an issue with the "Prevent users from changing the location of their OneDrive folder" setting not working.

 

I have added the Tenant ID in the "Value Name" field as instructed and added the value "1" in the "Value" field. Sadly users can still click on the link to change the location of the OneDrive folder during the intial OneDrive setup.

 

PreventUsersFromChangingTheLocationOfTheirOneDriveFolder.png

 

Any ideas Ronak or anyone else?

Currently investigating the issue, I've reached out to you over PM with some questions.

@Ronak Shah wrote:
Currently investigating the issue, I've reached out to you over PM with some questions.

As per my PM this was user error on my part - althogh the client version for my admin account had updated to the latest version, the standard user account was unable to access the update servers and was therefore stuck on an earlier client version which did not support the new GPO settings. Once updated, the GPO applied as per design.


@Jonathan Conway wrote:

I have trialled the new ADMX files that are included with the latest production client and have found an issue with the "Prevent users from changing the location of their OneDrive folder" setting not working.

 

I have added the Tenant ID in the "Value Name" field as instructed and added the value "1" in the "Value" field. Sadly users can still click on the link to change the location of the OneDrive folder during the intial OneDrive setup.

 

PreventUsersFromChangingTheLocationOfTheirOneDriveFolder.png

 

Any ideas Ronak or anyone else?


This was user error on my part - although the client version for my admin account had updated to the latest version, the standard user account was unable to access the update servers and was therefore stuck on an earlier client version which did not support the new GPO settings. Once updated, the GPO applied as per design.

Hoping I can get some help here too. We are looking to set the default directory to %SystemDrive%\OneDrive, as well as configure auto-configuration / logon via ADAL. We havent modified the admx/adml files as the latest feedback seems to indicate it's no longer necessary, but the net result is that with all the gpo's configured the onedrive client will no longer launch, it doesnt error, it opens in the task tray temporarily then just closes. I've added the latest admx/adml files (dated 10/20) into the policydefinitions store.

 

obviously i've mucked up something somewhere, but not sure where to start.

Hi,

 

Possibly not the issue with you given you'd have noted it before applying the new GPO's, but I had this issue with a customer. Turns out they had other GPO's which they had created previously to block commercial OneDrive accounts, and this also blocked the OneDrive for Business client completely.

As you say, no need to modify the admx and adml file.

Hi Dustin, could you direct message me with logs from your %localappdata%\Microsoft\OneDrive\logs directory? I can have our engineers investigate the issue. 

 

Thanks,

Ronak

@Ronak Shah Can you please have the requirement for admx edits removed from the documentation, if it's no longer needed?  This requirement is mentioned in both the Onedrive GPOS documentation and the Onedrive Known Folder redirection documentation.

 

https://support.office.com/en-us/article/Redirect-known-folders-to-OneDrive-for-Business-e1b3963c-7c...

https://support.office.com/en-us/article/Use-Group-Policy-to-control-OneDrive-sync-client-settings-0...

Well, after doing some additional testing, i was able to finally get the gpo to behave the way i wanted:

 

I was able to create the directory C:\OneDrive via GPO, and set this as the default when OneDrive first launches.

 

The reason we are doing this is a little long-winded, and since I have your attention, I would love some feedback on our use case:

 

For 90% of circumstances, it wouldn't matter if the OneDrive folder was buried in the user's directory, however, we have a few applications in our environment, AutoCAD and Adobe InDesign as two examples, that rely on literal pathing to fetch resources. This was fine when the resources were stored on a file server and made available either via UNC or a mapped network drive, the file was always stored in the same path, and any user that needed to open them would have no issues.

 

Well, OneDrive introduces a challenge here because the default storage location is unique to each user, which breaks that literal pathing. From a performance perspective, these applications are not very latency forgiving, and fetching the content directly from cloud storage just isnt a viable option, and some of these applications don't support HTTP addresses or even understand web protocols.

 

Secondly, we have been eagerly awaiting the release of Windows 1709 and the promise of Files On Demand, our initial testing honestly has us incredibly excited, its an amazing bit of engineering, we are actually now planning on migrating close to 90% of our file server content to SharePoint Online.

 

However, the catch we've noticed is that Files On Demand, since it writes directly to NTFS now to track sync status in attribute form, it takes quite some time for that content to be fully represented, its fast certainly, somewhere in the order of 3500 objects per minute, but when you're connecting to a document library or several that altogether contain over a million objects, it would take several hours before FoD finally wrote all theat data to disk, even if it was just "Online Only"

 

our hope, and i'm almost certain im going to be breaking something by doing this, is that if we wrote that data in a common directory, we could still be able to present the content on workstations that are shared or ad-hoc, like conference rooms where you never really know who is going to log in, and already have a representation of the online document library written to a spot that the next user's onedrive client could consume it.

 

ideally, it would be great if there was a way to speed up this initial sync of libraries in FoD, but i'll take what i can get at this point.

 

if i'm just crazy just let me know, but i'd love to hear back thoughts on our approach.

Hi Steve,

 

Thanks for your feedback. The major change we made was to no longer require direct modifications of the ADMX file. Instead, we rely on Group Policy Editor to allow specific configurations, such as Tenant -> Default directory mapping. 

I've reviewed the documentation below and none of them call out modifying the ADMX file directly. They do mention making changes in Group Policy Editor which is the new paradigm. Am I understanding your feedback accurately? 

 

Thanks,

Ronak 

Hi Dustin,

Thanks for your strong interest in Files On-Demand! It's great to see so much momentum around our feature. Improving the initial sync for Files On-Demand with large libraries is one of the improvements on our backlog. Once we roll this out, you'll see the update in our release notes. No ETA as of yet, since we're still rolling out our first version of Files On-Demand with the Fall Creator's update currently.

Regarding your use case scenario: Given that your applications (CAD + Adobe) rely on absolute paths, I think your approach of a default directory that isn't user specific is best. Please do let us know if you encounter any issues with these applications interacting with Files On-Demand.

Thanks,
Ronak

Thats good to hear, I'm continuing our testing and i'll kick back more feedback

@Ronak Shah In the first link I posted above, the first bullet point in the prerequisites reads:

"Make sure you installed the OneDrive for Business Group Policy objects on your domain, and updated the ADMX file with your tenant ID."

In the second link, under Prevent users from changing the location of their OneDrive folder:
"To use this policy, you must update the OneDrive.admx file in your Group Policy central store and add your tenant ID. "

Both of those lead me to think that I needed to edit the admx file directly, but at the same time have no instructions on what changes to make. That's how I came to find this thread.

Thanks Steve, sorry for the miss! I've submitted changes to the documentation. They'll be live once approved by our documentation team.

It's still quite odd to be editing the ADMX file directly.

@Paul Cunningham - Unless I'm missing something, no one should be editing the .admx file directly at this point.  There are a couple of leftover notes in the documentation which still refer to this, but @Ronak Shah is in the process of having those removed.  

That will be good when the documentation is all updated then.


@Ronak Shah wrote:
Thanks Steve, sorry for the miss! I've submitted changes to the documentation. They'll be live once approved by our documentation team.

When can we expect this to be updated?