So, we've got Windows 10 at RTM now, Microsoft's adventure into replacing the much-maligned Windows 8.x and the Modern interface with something more palatable. I have to say, early builds looked good - once you cut some of the cruft from the interface, it worked a lot more like Windows 7 and was far more easy on the eye than the crazy schizophrenic TIFKAM/Metro/Notro stuff. So I was quite excited to get my hands on the proper Enterprise build ready for a bleeding-edge deployment - would Windows 10 be as good in a roaming environment as Windows 7, and hopefully not more of the Windows 8.x nightmare?
Alas, as you can probably tell from the title, it doesn't look very hopeful.
I'm just putting this first article out with a quick summary of what I've found so far. I will be doing some more detailed pieces over the rest of the week, but I thought it was important to get the findings out there and hopefully see if others are having the same experiences roaming-wise, which personally has been quite frustrating and very disappointing so far.
Standard roaming profiles
Unlike the IE10 Cookies and History debacle, where I started with UEM products and finally got around to testing standard roaming profiles, let's start with roaming profiles this time! After all, this is Microsoft's recommended-ish way of doing stuff - even though most of you probably want the advanced features of UEM, it makes sense to start this way.
First, let's configure a standard roaming profile path for Windows 10
That's all cool. Now let's log in and make sure our profile is listed as roaming...
...and that all looks good. So we will customize our profile slightly by pinning some stuff to the Start Menu...
...and then log out to see if the profile is successfully removed from the machine and copied up to the network. We have the "Delete cached copies of roaming profiles" GPO enabled so the cached copy should be removed at logout.
Well, so far so good. Let's go back to the server and see if the profile is copied up to the folder we specified. We see in the folder that there is a profile folder there (note the .V5 extension automatically appended for Windows 10 profile types)
This all looks pretty straightforward so far, so we will log in to a different machine and see if we get our profile settings. Unfortunately, the first thing we see is a screen that we first became aqcuainted with on Windows Vista, and which I've seen quite a bit of, sadly, in Windows 10 as well...
Now, if you remember rightly from Vista this used to indicate a stale user entry in HKLM\Software\Microsoft\Windows NT\CurrentVersion\ProfileList\{UserSID}, but in Windows 10, no such stale entry exists (in the screenshot below, only the user -admin-jrankin has an entry in this Registry key area)
So there's already something not quite happy in the roaming profile. Attempting to sign in for the third time, however, actually allows us to log on, but having to make multiple logon attempts just to roam to a separate machine doesn't exactly give me a warm fuzzy feeling. On top of this, the logon takes absolutely ages - the roaming profile folder is under 1MB so I don't understand why all of a sudden I have a 120-second+ logon time.
Also, once I've logged in, I now don't see any of my custom Start Menu settings. This is because, like Windows 8.x, the "Modern" part of the Start Menu (which Microsoft have christened "Start" rather than "Start Menu", just to confuse) sits in %LOCALAPPDATA% rather than %APPDATA%. Specifically (and I can imagine Ben Whitmore shuddering here), it's a Jet Blue database that lives in %LOCALAPPDATA%\TileDataLayer\Database\*. Now I understand why they maybe wanted to put this in %LOCALAPPDATA% - imagine if you pinned an item to Start that wasn't installed on the machine, you'd get a corrupted or blank entry. But is it so much of a jump to think that, in an enterprise environment with standard builds, that we might want users to pin an Outlook and intranet shortcut to Start and have it roam with them to a different machine?
But hey, that's why we've got the whole UEM environment, right? So we could just use AppSense or RES or UPM or any one of all the other vendors to roam the database for our users, shouldn't be a problem?
But before I get into that, let's just finish off with a quick review of how a standard roaming profile works. Well, it's not very good in the testing I've done. In fact, it's terrible. Logging in seems to take a very disproportionate amount of time and sometimes you can't log in at all, or get lumbered with a temporary profile. And sometimes I saw this when I logged in!
When it's not crashing or failing the logon, some settings roam around properly, other ones don't and clearly need a bit of modification under the hood or perhaps a fully-fledged UEM solution. It feels like more of the same from the IE10 Cookies shenanigans (which eventually they kinda half-fixed). I know there's all these Universal Apps to consider, and the pushing of the Windows Store as the new delivery point, and the ever-present spectre of Azure hovering over us all, but FFS Microsoft, some of us just want to deploy Windows 10 to enterprise users and have them roam from machine to machine just like they did in Windows 7 without any issues. Is it seriously too much to ask?
UEM solutions - the waters get murkier
Now, if you bring AppSense or another UEM product into the mix to give yourself the capability (for example) to capture things like "Start" settings, you can imagine maybe the problems go away somewhat? I've only done a limited bit of testing on this so far, but initially I get the impression that, well, it just makes things even worse.
When you set up AppSense to use a local profile or mandatory profile, the database we mentioned earlier seems to permanently stay in use by the operating system. At logoff, the profile cannot be purged properly and the database files remain behind. Even worse, if you use the "flip-to-temp" trick the "TEMP" username seems to get written into the database, rendering the database absolutely corrupt and unusable if you roam it via Personalization Server. This manifests itself by not being able to left-click on the Start button - the menu doesn't appear at all. The right-click menu is still there, but the standard left-click one appears completely destroyed. The only way around this is to delete all of the data and start from scratch, unless you fancy temp profiles forever - it's the "profile reset" all over again.
It's a system service called the "State Repository Service" (sounds like a bunch of American bank guards) which hooks into the database and holds on. This service cannot be stopped or manipulated in any way, as far as I can tell.
There is another service called "Tile data model server" which, when stopped, allows you to copy these files, but again even when this is done, the database still appears corrupt when restored to the user. I am currently testing with the same trick we used in IE10+ for the Cookies (marking the profile as roaming at logoff rather than temp or Guest), but this has been a bit inconclusive so far. I'm hoping to get some more investigation on this written up fairly soon - stand by!
Summary
So once again Microsoft seem to have a vision where they discourage people from using traditional roaming solutions or any of the third-party ones out there. This obviously seems to fit in with some strategy they have in mind, where maybe they drive the PC-using world towards a utopia where everyone uses the Windows Store and roams their settings via their Microsoft account, but this just doesn't fit in very well for the here and now where I want to deliver a Windows 10-based desktop solution that allows users to work in much the same way as they have on the previous one. I'm not even going to get into the fact that you can only (as with Windows 8.x) deploy Start settings through Group Policy if you accept the fact that the user won't be able to modify them. And the fact that if you disable Windows Update it turns itself back on without any intervention about a day or so later. And that OneDrive can only be removed via a custom script and it reinstalls itself without asking. And that the bloody Jet Blue database they're storing some settings in gets corrupted if you even talk about it nastily. And the pathetically long logon time I'm seeing. And - well, I'm going to start going even greyer, I will just leave it for now :-)
But I'd be very interested in hearing from fellow bleeding-edge masochists like myself about their experiences with roaming Windows 10 settings from machine to machine. How are you finding it?
Anyway - updates to this Windows 10 series very soon with more technical details and investigation, and there may be a new home for The AppSense Bigot coming up in the very near future....stay tuned.