Redirecting Folders to Office 365

I created a script a while ago to map folders at logon to enable saving directly to OneDrive for Business (also known as SharePoint Online or SkyDrive Pro). I plan to explain more on this but it was the script I mentioned in my #SYN119 presentation at Citrix Synergy 2014.

This script is now up and published on codeplex and is under the GPLv3 license (a copyleft license). Feel free to use and modify if you can help. Below is a slight description of what the script does and why it was created.

This project is to enable the use of Office 365 as redirected folders in Microsoft. Specifically, this script and method can be used on a Windows 7 desktop (or higher) with Citrix and roaming profiles (or any persistent profile method). What makes this unique is that no local storage is used (unless you can’t connect to office 365 and then it’s only temporary).

This script was developed by Tyler Bithell and Tom Gamull for a customer implementation. The customer desired a method to eliminate the use of local or shared storage and leverage their Microsoft Office 365 subscription.

You must have a subscription that gives you the SharePoint Online (Groove, SkyDrive Pro or OneDrive for Business). This is NOT the same as SkyDrive or OneDrive (these are just an online storage method, like Dropbox).

We leverage a method of WebDAV drive mapping utilizing NET USE. Although you can utilize OneDrive for Business for Microsoft Office applications directly, non-integrated applications are not able to be used except through navigation to the folder. This is often a problem for task works, students and others used to using My Documents or Downloads. Therefore this script was created to deal with this issue.

The script was announced but not shown at the Citrix Synergy 2014 conference in #SYN119. This script will also be discussed in the Cisco Live session Tom Gamull is presenting on Atlanta Public Schools.

16 thoughts on “Redirecting Folders to Office 365”

  1. I am having trouble implementing this script at a school district in the detroit area. They use o365 with ADFS integration, but the script continually fails at mapping the I drive. The variable is set properly, but the drive fails to map. If the user logs into their share point site, clicks the “view in explorer” button, and then manually maps the drive, all is fine. I believe all of the internet explorer settings are set up properly, and there are no group policies effecting the test desktop (it’s in an OU with inheritance blocked).

    This will be in a VMware View environment, but we have not tested that far, as we cannot get the I drive to map.

    Any suggestions?

      1. I thought that could be it, but even with a local admin as the user, it won’t work (i commented out the section that checks for that)… It’s really weird… Like I said, as long as the user clicks the open library in explorer button, the drive mapping works perfectly. GAH. By the way, excellent job on this script… 🙂

  2. It does the authentication, I turned IE visible, and I see it load the o365 portal, then a few seconds later, it loads my one drive library, then it closes. The script fails at NET USE I: $mappath

    System Error 53, can’t find path.

    If i catch the IE window while it’s sitting at my one drive and click the open in explorer button fast enough, the rest of the script completes successfully. Could this be an expected behavior for the first login and that the token would be saved for subsequent logins?


  3. I had this happen and looped the script about 3 times, worth trying. My thought was it’s not pulling an IE command but if it’s not that I might be out of ideas (at the moment).

  4. Great solution. Have you used this with a federated domain? Any issues with getting the token in ADFS 2012 R2?
    We are able to do the manual drive mapping but but can’t figure out why the script is failing to map the drive.

  5. I think we answered our own issues, and got it working. But it seems that the checkbox on the site has to be checked and we can’t do it without that, and that means that login.srf must be visited first before AD FS every time. Any way around that?

    1. It should do that through the automation part, it runs as the user, selects the box to remember login, and then that cookie (the 2nd one) is stored so you don’t have to do it again. You have to run the script once per user to do this, then the second time it will work. You could also just ask the user to logoff. In our scenario, the students had not received passwords yet so we scripted the user login with Login VSI.

    1. I’m sure it could but the script really addresses the token issue with office365 and drive mapping. I believe sharefile integrates with the receiver and can be used in that way (so it’s easier and you don’t need the script)

Leave a Reply

Your email address will not be published. Required fields are marked *