I mentioned in my first look at Windows 10 how annoying I was finding it roaming the “Start” settings (Start being the name Microsoft have coined for the “live tiles” part of the Start Menu). After a good deal of tinkering, it seems I’ve finally found a way to do this reliably, so let’s quickly document it up before I forget!
Update 22/03/2016 – there is now a better way of achieving this that I’ve documented see this article for the new method
Obviously there are environments where users are bound to dedicated PCs and the prospect of “hot-desking” between many different Windows 10 devices is unlikely, but I find that even if you’re not in a “hot-desking” environment, it still makes sense to put provisions in place for users to roam settings like this. In all the presentations I’ve done recently I’ve mentioned that the user experience is key. More and more times I hear people referring to the “Apple experience” and intimating that users expect the same level of reliability and simplicity from enterprise IT systems as they do from their iPads or iPhones. Putting something in place to ensure that users get a consistent experience from their Start tiles is one way of enabling this kind of smooth roaming that gives people confidence in the systems they’re using. For me, one of the first and most annoying things about Windows 10 was unpinning all the crud from the Start area and bringing the Start Menu down to a more “normal” size, and having to repeatedly do this across different machines was becoming a bugbear. As an example, here’s the default Start area you’re presented with…
and here’s something approximating what I’d like it to look like, regardless of where I log in.
Now if I log in with a local profile obviously these settings will persist only on that particular device for as long as the local profile is there, but in many environments people need, for whatever reason, to roam from device to device. Even if they don’t do it much, it adds to the overall positivity of the user experience if this capability is there. You may disagree with this, but I like users to have a smooth, reliable and predictable experience across as many devices as possible that lends itself to a more productive working day, and I’m sure many out there will agree with me.
Roaming has always been a big part of any environment, particularly those where users are mobile or RDSH/XenApp or VDI is in use, so I think it’s important to replicate this, particularly in environments where users have grown accustomed to it. They don’t want a nice shiny upgrade to Windows 10 and then find everything behaves differently and annoyingly, do they?
I did my testing on Windows 10 Hyper-V virtual machines using the x64 LTSB Enterprise edition. I also used (for this article) a standard Microsoft roaming profile.
The problem is that the standard Microsoft roaming profile, which now seems a lot more reliable for roaming settings than it did in my first article (no temp profiles, no blue screens, no profile load failures observed this time – obviously something has been patched in the background), simply doesn’t save the Start tile settings, as these are in %LOCALAPPDATA%. As I said previously, this avoids the issue of users pinning application shortcuts to Start that simply aren’t present on other machines, but we will go over that eventuality in a later article. For now, I’m assuming that the Windows 10 machines are identical in terms of application sets and if a user tidied up their Start area, you’d like it to roam with them to their next machine.
I’ve also configured the GPO on these machines to disable OneDrive and to delete cached copies of roaming profiles. For starters, we will work with a standard roaming profile defined on the user object in Active Directory.
So, let’s log in and see what’s what. Most of the things we do save OK to our roaming profile – pinned Taskbar icons, MRU lists and the like, they all roam OK. But the Start tiles don’t – if we log in on a new machine, we simply get the defaults for the Start tiles. Annoying and frustrating!
 |
| Annoying to see the defaults when I roam – incidentally this is the default settings for the Start area on Enterprise versions of Windows 10, very threadbare! |
Now, in our previous article we mentioned that the settings for the Start area were in %LOCALAPPDATA%\TileDataLayer\Database\* and that they were locked by an operating system service, the State Repository Service. However, there was also the Tile Data Model Server service which seemed to “unlock” these files for manipulation.
An anonymous commenter on the previous article mentioned they’d had success with the latter of these, so that’s what we’ll be trying to do. Firstly, let’s funk our Start area up with some pinned items and rename the groups
Now, we’re going to bring AppSense Environment Manager into the mix. You could do this with a logon and logoff script, but the key functionality I’m invoking AppSense for is the capability to run an action under an elevated user context (specifically, we’re going to mess with a system service). If you wanted to do this with a logon script I’d recommend using some form of elevation (CPAU, maybe?) to handle the service manipulation. Of course, I’m sure many other UEM products could do the job – RES, Liquidware Labs, Scense, etc. – but as the nice folks at AppSense give me NFR licenses, it would be rude not to use them 🙂
So firstly we will drop the necessary agents on the machine. I’m still going to use a roaming profile for now and leave Personalization Server turned off – I’m specifically going to concentrate on roaming these particular settings. At the moment, all my testing with Personalization Server to roam these settings seems to result in me actually breaking the left-click functionality of the Start Menu – i.e. it doesn’t respond at all to clicks! – so I’m fairly sure there is something AppSense need to do to allow Personalization Server to function with the new Start tile stuff.
Anyways, let’s simply set up a couple of Actions, one at Logon (Desktop Created) and one at Logoff. The Logon Action is very simple…
This will copy the files from the home directory into the %LOCALAPPDATA% path. Obviously at first logon this won’t copy anything, but on subsequent logons will do.
And now for the Logoff Actions. The key part here is the first – we need to stop the Tile Data Model Server service. I’ve used net use for this, but if you’re more cool and down with the kids you may be more interested in using PowerShell’s stop-service cmdlet – the choice is yours. You don’t need to restart the service afterwards – the service recovery option in the operating system will restart it within a few seconds, but give you enough time to get the files copied.
This simply runs the relevant net use command. Note (highlighted) that I had to uncheck the “do not create window” option – it doesn’t actually show the window, but wouldn’t work with it checked, no idea why
Obviously, as we are messing with services, this needs to run elevated
Once the service is stopped, the edb and edbtemp files will be available for copying, so we simply need a reverse of the action we used at Logon
So the whole Logoff action, correctly nested, should look like this
Once we’ve deployed this, I’m going to logon to a different machine and see if I get the Start layout I saved before…and hey presto! It works. But now let’s make some changes to the layout, making one group of icons smaller…
…and then log in to a different machine…
….fantastic, the settings are all there.
So that’s how we can do it, using either AppSense, a scripted method, or some other UEM product. But there are some caveats:-
- I haven’t tested this when a user is logged in to multiple sessions simultaneously
- There is no compression going on, so there’s about 11MB of files (which may grow) to bring in at logon and logoff (so I’d rather this could eventually be done in PS)
- Occasionally the logon dragged slightly, but this is a damn sight better than the profile failures, blue screens and weirdness seen previously
- >This was done purely using AppSense EM as an addendum to a standard roaming profile
- I haven’t tried pinning application shortcuts for applications that may not be installed on other devices
- This definitely wouldn’t fly in an RDSH/XenApp environment (as and when the Server 2016 operating system becomes available), because stopping a system service at logoff on a multi-session environment wouldn’t be a good idea, methink
- It’s very easy to break the database and leave yourself with a non-functional left-click Start Menu. Getting the wrong files in the directory you’re copying or getting the wrong username written into the database – there seem to be many things that will completely corrupt the data and leave you having to delete it to fix, so take care with your data integrity. Even a failure to copy them properly seems to give it issues
Over the next few weeks, I’m going to continue this Windows 10 series and have a look at at many of these issues as possible, particularly with regards to concurrent sessions, local/mandatory profiles and also trying to provide a customized default set of Start tiles that can then be configured by the user. But, this is an improvement over the situation I was in previously – it can now be done, albeit with some unnecessary jiggery-pokery to manage it. I’m not even going to bother having my standard Microsoft-whinge – they clearly don’t listen, unlike many of the other vendors I deal with.
But for those of you frustrated at the prospect of having the default set of Start tiles at every new device logon, hopefully this allows you to get over this hurdle and continue your evaluations/deployments!
Share
