Sign up for Office 365
Learn more about Office 365
Another day, another issue with Office 365 and mapped drives.
This time we have a customer with 5 client machines. 3 x Windows 7 and 2 x Windows XP. The customer is running sharepoint plan 1.
They are using the sharepoint as a way of storing files in the cloud and accessing them via a mapped drive.
The windows 7 machines. while we had some fun and games initially, they all work fine now.
The Windows XP machines however are not playing ball. They can log in to the team site. They can view files online, they can even click the "open with explorer" which works ok. However mapping a drive to the team site throws this error:
"The network path https://%3ccustomername%3e.sharepoint.com/Shared%20Documents/ could not be found"
(I have changed the customer name to protect their identity).
No matter what I try I cannot get round this issue.
So far I have:
all with no joy. I have one very unhappy customer. Can anyone suggest something I may have missed or why this is not working?
Thanks in advance
Thanks for the feedback.
First, thank you to mch for helping Darren out thus far. I'll comment on all points now.
In response to the points made about the Microsoft Online Services Sign-In Tool, please note that this tool was put into place for the Business Productivity Online Suite (BPOS) offering, centered around the 2007 SharePoint/Office suite. I'll get into the authentication model more soon but, for now, just know that this tool is not applicable in Office 365. There is an Active Directory Federated Services (ADFS) tool available to Enterprise subscribers that have their own Active Directory but this would also not apply to the typical subscriber.
Now, to the authentication model in Office 365. Unlike in BPOS, where a certificate-based system was put in place to allow for a single sign-on experience, Office 365 uses a claims-based authentication model. When you sign into Office 365, you create a SAML token that sits in your browser for about 12 hours before expiring. Once the token expires, it will invalidate mapped drive connections until you authenticate again. This is a security feature of Office 365 and will occur regardless of your environment.
Regarding environmental concerns, it's important to note that XP typically forces you to use the UNC path for mapping network drives. On those machines, you're going to want to structure the path like \.sharepoint.com\Shared%20Documents\ instead of engaging a hypertext protocol of some kind. You may also want to try setting up a Network Place via the "Sign up for online storage or connect to a network server" link in the Map Network Drive window. I see you've tried editing your environment to a degree and there's some good work there. With the Local Intranet zone in Internet Explorer, we recommend you put in https://*.sharepoint.com, https://*.microsoftonline.com and https://*.onmicrosoft.com. You noted you placed similar links into the Trusted Sites zone, which is where we'd want to see your complete SharePoint Online URL for any site collections you have. Trusted Sites at least should have all ActiveX controls enabled to ensure all controls are tapped when needed. As for registry adjustments, we recommend you navigate to \HKLM\SYSTEM\CurrentControlSet\services\WebClient\Parameters and add the AuthForwardServerList parameter with keys matching the URL's I noted above. After that, make sure the WebClient service is running or restart it if it already is.
Thanks for the reply MCH
I am currently running a load of updates on the machine and will try the sign in assistant as you mentioned.
Can I check though, I have a utility downloaded called the "Microsoft online services Sign In" is that the same thing?
I dont suppose you have a download link?
Ok so I have installed something called the "Microsoft Online Services Sign-In".
This installed, but would not accept the username and password at all, I tried with several different Office 365 logins we have and none were accepted.
Uninstalled and then found this: www.microsoft.com/.../details.aspx the Microsoft Online Services Sign In Assistant. Downloaded and installed.
then what? there is no program in the program menu, there is a service called Microsoft Online Services Sign In Assistant, which is started. Thats it. The problem with mapping the drive is still there and nothing is improved.
I noted however the version I downloaded in is 2.5 and not 7.5, but I will be buggered if I can find the 7.5 version.
Office 365 is soooo near being the answer to small businesses IT woe's however this login thing is soooo disjointed as to be unfunny.
I'm pretty sure I got this sign in asst doodad from MSFT support. In an early beta account, "open with explorer" was grayed out and a service request identified that the early beta set up was flawed and they provided this version of the program. So it's been sort of working in subsequent accounts.
Found it-if you want to dload it, it's here:
Sign in asst zip
Your detailed response is appreciated but with all due respect, it highlights one of the issues many "average" users are experiencing with how intuitive O365 is. With a service this sophisticated, people expect commands like "Open with Explorer" to either work or to alert them to the reasons why it might not work. If all these required tweaks and settings are known, shouldn't they be baked in behind the scenes somewhere in the software? Expecting people to ferret around in a forum for an explanation isn't really a solution..
As for the "Sign In Assistant" not being applicable to 365, I can only wonder why it was provided to me by 365 support and why it apparently did solve the problems I had with the open in explorer functionality.
I too appreciate your detailed explanation, but I've heard all this and the issue still persists. On the front lines working with customers this aspect of Office 365 is embarrassing. I've reported this issue back in July and was told a "fix" was coming. PLEASE we have to get this corrected. I've lost one client over this issue and next week I am going to setup another client who wants to utilize the total ingtegration of SharePoint and Office, and I'm at a loss as to what to do.
I have not been very successful at setting up a mapped drive directly to point to a SharePoint Online Library so I just copy the URL to the Windows Explorer Favorites. It works great until the SharePoint credentials expire then you get the foul error message:
"\\bluecloud.sharepoint.com©SSL\DavWHWRoot\Clients 2 is not accessible. You might not
have permission to use this network resource. Contact the administrator of this server to find out
if you have access permissions.
Access Denied. Before opening files in this location, you must first add the web site to your
trusted sites list, browse to the web site, and select the option to login automatically."
Sometimes (rarely) I do get prompted to enter my O365 credentials, at this point, which is fine and how I would expect it function.
I've done the add sites to trusted sites, but no help there.
This issue really needs to be taken seriously! Any help would be greatly appreciated...in either driving Development to correct this problem or providing a work-around.
I appreciate everyone's patience in awaiting a reply. Also, thank you for your candid comments on our products. I can assure you that such comments do not go unnoticed by those who work to improve the end user experience for all.
With that said, we do need to remember that the root of almost all such issues is the local machine. Windows XP, for example, was designed around an earlier system architecture and was only later adapted to 64-bit. SharePoint 2010, on the other hand, is only 64-bit and employs all the newest standards. When SharePoint asks your local machine to, say, engage WebClient to create a WebDAV bridge for transferring content, SharePoint itself is doing all it can. It cannot influence the configuration of your local machine or operating system, it can only try to "talk" to the machine. Barring extreme configuration issues (of which most can be readily remediated) on the SharePoint side, it would be your personal computer that is struggling to maintain the WebDAV bridge. This is why we suggest such an array of configuration options, to try and improve the quality of communication between the two. Until this line is blurred by ubiquitous cloud technology, configuring your local machine to interoperate with server software is going to be a necessity; SharePoint included and excluded.
Again, Patrick your explanation makes a lot of sense and I'm sure we wouldn't complain if it weren't for the fact that we've all used other connection dependent services that don't seem afflicted with these issues and the issues don't seem limited to older operating systems. Sharepoint may bring a new degree of complexity to the table but compatibility with widely used operating systems -even older ones-seems to me like it should be a priority and addressed before a product is deemed market ready. The cloud is worthless if you can't reliably reach it.
I'm sure you understand that advising potential clients they must upgrade all their operating systems and do all kinds of tweaks in order to enjoy the benefits of O365 isn't exactly a compelling sales pitch.
Patrick, as MCH says, thank you for your clear and concise answers. They are accurate but at the same time don't help with the client experience.
The issue is not XP only. I have Windows 7 Pro machine, with Office 2010 Pro and IE9 and still see similar issues when mapping drives. Sometimes it works and sometimes it doesn't
Putting that aside, as MCH says, in this day an age when we do have problems with mapping a drive it should be possible for you to display a reason why it is not working. When clicking the open with explorer button a message stating "Your computer does not support opening this list" is nonsense, it should check for the trusted, intranet and web service and if it cant sort them itself provide clear instructions on how do so.
Office 365 is unique to us IT companies as when it works, it takes v little support from our side. However little issues like the one above caused me to have to give a customer their money back and go through the cancellation. THis costs us time and money that we cannot afford in the climate. It also makes us look bad in front of the customer.
I have started a discussion thread here: community.office365.com/.../16908.aspx outlining some of the more common problems I have come across and that have yet to be resolved by MS.
Did you's manage to get a resolution to this mapped drive issue? I have the same problems of windows XP machines.
No, I've never seen a resolution. Everytime another user reports the problem, MSFT responds with differing, possible explanations and then the responses stop. I've no idea if they're pursuing a fix behind the scenes or not. Meanwhile, if it's a required feature for a user I'm forced to steer them away from 365.