I'm trying to get my sharepoint workspaces on office 365 to mount like network drives. I can achieve this following microsoft guidelines, but after a while this fails. The user has to login again to their 365 account, and then remount the drives.

This is time consuming and annoying and with 50+ users you can understand that would produce a bucket load of support calls.

I've given this issue to microsoft to deal with and they have explained that because of the use of form authentication, the drive mapping will time out after 2 hours. (I can't be bothered to find the email just yet - I'll add it to this question if it's requested.)

I'd like to know if others have suffered this issue, and found a workaround? Or is there a way to prevent this disconnection?

  • Have you looked at the network traffic with WireShark when the connectivity is lost? Mar 18 '12 at 22:20
  • It's unpredictable the moment of disconnection Mar 19 '12 at 12:40
  • I would still run a capture just to see what is going on. With computer systems when we say "unpredictable" what we normally mean is that we don't understand why it occurs when it does. If you can run WireShark on your machine and look over the logs it might help yo understand why it is occurring when it does. Mar 19 '12 at 12:52
  • 1
    I understand fully why it occurs - Office 365 uses form based authentication, and this SAML token expires every 2 hours & after that the mapped drive for SharePoint library cant access the resources unless the user signs in to the site again from the browser. - WHICH IS STOOPID MS! Mar 19 '12 at 14:50
  • This has been confirmed by MS already so - please believe me :) I would like to write a power shell script to automate the logging in, and also mounting the drives Mar 19 '12 at 14:51

How about trying this? Create a PowerShell script that runs every 1.5 hours and downloads the contents of a page? There are a few things that you might try, like just using get-content of a very small file on the mapped drive or something as complex as

    $request = [System.Net.WebRequest]::Create("http://companyweb/");

    $cred = New-Object System.Net.NetworkCredential
    $cred.Domain = "MyDomain"
    $cred.Password = "MySuperSecretPassword";
    $cred.UserName = "username";
    $credCache = New-Object System.Net.CredentialCache
    $request.Credentials = $credCache;
    $request.Credentials = $cred;

    $response = $request.GetResponse();
    $requestStream = $response.GetResponseStream();
    $readStream = new-object System.IO.StreamReader $requestStream
    $data = $readStream.ReadToEnd()

::fixed see edit:: Notice if you use something like the second option you need to point it to an actual page. For some reason if you point it to an URL like http://companyweb/ when it redirects to http://companyweb/sites/home.aspx the request forgets the credentials (which makes me think this method may not work). ::fixed see edit::

Obviously this is not the most secure method as the password is in clear text in the script but since you cannot use DefaultCredentials (SP Online uses forms, right?) there is not much else you could do... I'd also suggest you make a dummy page for this purpose that has no text or web parts on it, just a blank site page. Even if this does not work, I hope you find a solution!

EDIT: I added a credential cache object which may actually make this work.

  • YEAH BABY! Now THIS looks promising! My friend, I shall work on this code, I'm taking a crash course in Power Shell and I will solve this issue dammit! :) Mar 21 '12 at 7:49
  • Any progress? Just wondering if this actually did anything for you. Mar 22 '12 at 19:54
  • As soon as I told my manager I had a lead of the solution, he pulled me off it happy there was a light at the end of the tunnel, and I've spent the week bedding in new clients. I guess I'll be spending my weekend working on this! Thanks for the followup! Mar 23 '12 at 17:09
  • I'm super curios about this. Feel free to get in touch via email. It's on my profile page. Mar 23 '12 at 17:11
  • I tried to get back to you via email - no joy, but I've finally got time to work on this, I'm testing this out today, would really appreciate your input. Apr 5 '12 at 10:36

Its by design.

See this article: http://blogs.technet.com/b/lystavlen/archive/2011/10/06/how-to-access-a-office-365-document-library-from-windows-explorer.aspx

  • While this may theoretically answer the question, we prefer inclusion of the essential parts of the answer here, and to provide the link for reference. See answer for general guidelines.
    – SPDoctor
    Mar 19 '12 at 19:02
  • I know it's by design - I'd like to work around this. My question was has anyone found a work around, or a way to prevent this from happening. I was considering using Power Shell to "maintain the connection" and remapping the drives if they get disconnected. I am trying to work around this 'design feature' Mar 19 '12 at 19:34
  • Sounds like poorly thought out design. There seems to be a dangerous disconnect between the MS engineering team and the user community here.
    – cs31415
    Apr 5 '12 at 16:27

I encountered the same problem… After reading many blogs, articles, presentations, code samples… etc I decided to develop/assemble an utility being able to set the necessary SSO Cookies in an unattended way for domain PCs and servers.

After running the utility you will be able to mount the share without user intervention with the usual “net use…”. Maybe scheduling the utility every one or two hours could solve the problem.

It’s the initial release, so no guarantee it will work in your environment…

Anyway if you want to give a try, here is the link to my blog with source code and an exe version too.

Your Answer

By clicking “Post Your Answer”, you agree to our terms of service, privacy policy and cookie policy

Not the answer you're looking for? Browse other questions tagged or ask your own question.