I'm still stuck trying to complete the world's most infuriating post - one on setting up a default Windows 8.1 Start Screen - so while I struggle against this, I thought I would put out something a bit shorter and sweeter that I actually know might work :-)
I had a requirement recently to set up a mapped drive for a WebDAV share. This wasn't something I'd come across before, so it's not necessarily a common requirement. However, as document management systems become more and more commonplace, we may see more of this, so I thought it would be a useful exercise to document.
What is WebDAV?
WebDAV stands for Web Distributed Authoring and Versioning (WebDAV, from now on). It's an extension of http that essentially makes web documents a readable and writeable medium. Lots of operating systems have built-in WebDAV support. Windows added client support back in Windows 98 which some of you may remember seeing as an OLE folder titled "Web Folders". It was built in to Windows 2000, and Windows XP added a Web Client service which functioned as a WebDAV mini-redirector. Operating at this level allowed WebDAV shares to be accessed via drive letters and UNC paths from Explorer, via any piece of software. WebDAV is mainly used for file sharing, in the same way that FTP can be.
It's worth noting here that WebDAV over https will only work if KB907306 is installed, so if it is an https path you are connecting to, you will need to ensure that this in place. If you encounter any additional issues around https paths, ensure that the Registry value below:-
HKLM\SYSTEM\CurrentControlSet\Services\WebClient\Parameters\BasicAuthLevel
exists and is set to a REG_DWORD value of 2.
We are dealing with Windows 7 / 2008 R2 and newer clients in this article, so you may have to perform some further actions to get this to work on older platforms. However, given that Windows XP is out of support anyway, maybe you should be thinking about problems other than mapped drives, in that situation?
Connecting to the share via a mapped drive
First of all, it is easy enough to configure a mapped drive for a WebDAV using Group Policy Preferences - this is supported natively by Microsoft's tools...
However, as most AppSense DesktopNow customers generally use Group Policy to manage the devices, and DesktopNow to manage the users (some use DesktopNow for both users and devices, in my experience), we need to find a way of doing this through Environment Manager itself.
Unfortunately, the native AppSense Environment Manager Action does not support the path to the WebDAV share...
...which is rather annoying, seeing as though GPP can do it without issue.
But wait....can we do it using PowerShell?
Well, there is the cmdlet New-PSDrive, which (when combined with PowerShell 3.0, which allows you to use the -Persist switch to make the mapping available beyond the PS session) looks like it may do the business...
New-PSDrive -Persist -Name L -Root https://WebDAVexample.jrr.test.local -PSProvider FileSystem
....but sadly doesn't. The -PSProvider switch (which can be FileSystem, Registry or Certificate) doesn't appear to cut it with WebDAV - you get the error "drive root https://WebDAVexample.jrr.test.local does not exist or it's not a folder".
Hmmm. What else can we try?
Let's not forget that PowerShell also supports old legacy commands, so will using these make any difference? Why don't we try this from PowerShell...
net use L: https://WebDAVexample.jrr.test.local
....and oddly enough, this seems to work! Whatever the legacy net use command calls under the hood allows it to connect up to the WebDAV location where the New-PSDrive cmdlet can't. So now we can import our WebDAV drive mapping into Environment Manager.
We will use Actions | Custom & Execute | Custom Action to do this
Also note we have set the timeout to 10 seconds. In certain situations (if your proxy server and exceptions are not set correctly, for example) the PowerShell command may stall waiting for the user to input authentication. To avoid any issues with this, we've set a specific timeout. Unfortunately the PowerShell host seems quite slow to map the WebDAV connection, which is the reason the timeout is set so high. However, if everything else is configured OK, this shouldn't be an issue - naturally, test it thoroughly!
Once we've done this and deployed it, we should now see the L: drive available from all of our user's applications. The WebDAV share can be browsed and accessed normally from all of the installed apps - a good all round result.
The only caveat I would make is that if this drive mapping isn't absolutely necessary, then don't map it at logon - it does seem to take a few seconds to map a drive in this way. If possible, restrict it to a specific group - or use the EM 8 FR 5 Desktop Created trigger to call the mapping Action, or a Post-Logon Offload Trigger if you're using an earlier version of EM.
Anyway, hopefully this should prove useful if you need to provide WebDAV share drive mappings and you're an AppSense DesktopNow customer. Now I will get back to the hell of trying to get a default Start Screen layout to successfully apply - may it not be long before the article is finally published!