Quantcast
Channel: HTG
Viewing all 178 articles
Browse latest View live
↧

Deploying per-user file type associations in Windows 8.1 / Server 2012 R2 and beyond

July 13, 2015, 1:21 pm
$
0
0
Well, this started out as a blog post about FSLogix Apps. But - we ran into a problem pretty quickly. Namely, that from Windows 8.1/Server 2012 R2 onward, you can no longer deploy per-user file type associations (FTAs). So if you've got multiple users on XenApp/RDS platforms and you want to give individual users different FTAs, you're going to be up against it.

Firstly, why would you want to do this?

Well, let's imagine a XenApp environment where you might want users to open files from the same server but with different apps, possibly for licensing reasons. You might want some users to open Visio files in Visio, and others in Visio Viewer. Or you might want some to open PDFs in Adobe Reader but others in the full version of Acrobat. Prior to this, you could simply use Group Policy Preferences Folder Options to deploy an Open With item. Each user would get a particular application associated with a particular file extension. Nice, easy, uncomplicated.

Whilst writing a post on FSLogix, it became blatantly obvious that something had changed under the hood (it's IE10 all over again! Urgh!) The Group Policy Preferences method I wrote about previously simply flat-out doesn't work any more. Normally, user FTA settings are written to a specific Registry area - HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts, with subkeys for each filetype (e.g. .PDF). But Microsoft appear to have changed something. Now, when you write a new filetype using the Default Programs part of Control Panel (or the Default Programs context menu), the Registry settings are changed in a very different way.

To show you what I mean, I've logged on to a Server 2012 XenApp system with three different PDF readers installed locally, and I'm going to select FoxIT Reader as the application to use. The way I trigger this is by right-clicking a PDF file and choosing Open With | Choose Default Program, but you can also access this through the Control Panel.


Once I select FoxIT Reader as the default program, we can see the Registry changes we'd expect - but there are some additions we haven't seen previously


Note the Hash value. Apparently, this is a hash generated from the application, the computer name and the username, and which needs to be unique. So if I export these values into the user profile and roam them to another XenApp server, the FTA will be lost. If you export, roam, save or persist this Registry key, when you move to another server system, you are prompted to choose the default program again, because the hash doesn't match. Apparently this was done to reduce tampering by malware, but it's very short-sighted because it doesn't take into account multi-session systems like XenApp and RDS.

Even more annoying, is the fact that the action of setting a default program in this way also writes a permissions change to the UserChoice key. See below


Note the Deny set for the user account that made the change (in this case I was logged on as Administrator). This means that you can't set the values in this key through a script or such like without altering the Registry permissions first. But even if you do alter the permissions, you need the Hash value to match the server system - and without knowledge of the algorithm in use, you're not going to get very far.

However, Microsoft have handily made a function available for setting the file associations. This involves setting the file association(s) for a user, and then exporting it(them) out to an XML file using the following command


Once you've exported the XML file with your configured file associations (you can edit it by hand to just get the FTAs you need), you can then deploy this at logon by using a Group Policy Object. This all sounds good so far...

...until you realize that the GPO that sets the FTA is Computer Configuration only. That's right, it writes to a Registry key in HKEY_LOCAL_MACHINE. Making it a royal pain in the proverbials for deploying to multi-session environments such as XenApp. If you don't believe me, check it out - it's to be found only in Computer Config | Policies | Admin Templates | Windows Components | File Explorer


So somehow, we need to set this HKLM value for each user individually. The Registry value appears to be read at logon and the FTA is set at that point (meaning that the values are then written to the HKCU FileExts key) - so maybe we can get around this if we can find some way of deploying a HKLM value based around the user context?

Just for posterity, here's a diagram detailing how I believe that this now works (based on my own research and observations)


This is how it seems to work in practice - so maybe we can leverage Group Policy Preferences again to make it operate on a per-user basis. Alternatively, you could use AppSense, RES or any other software that allows you to set HKLM entries on a user-based condition, but GPP seemed the most logical to choose given that most environments have access to it.

Not that we're not going to use the actual Group Policy Object to achieve this - we will use the Registry value that the GPO sets. This is because as a Computer Config GPO, filtering based around user-based conditions is very difficult, if not impossible, but if we do it as a GPP Registry Item we can use Item-Level Targeting on the user level.

So, first we need to log on as a user and set the default associations (in this case, for the PDF file extension) to each of the required applications. Once we've set each one, we need to export the associations out using the following command (note that the file path must exist prior to running this)

Dism /Online /Export-DefaultAppAssociations:filepath\filename.xml 

When you've done this, you should have an export file that looks something like this


You can now strip this down by hand to get the file associations you require, such as shown below


Repeat as necessary for however many FTAs you need to set up.

Now you need to put these files on the local machine. Yes, you can't use a network share - increasing further the overhead and unwieldiness of this solution. You could use GPP or AppSense EM to copy files from a network share, but you must have the XML files local to the machine. In our case we've created a directory c:\Assoc - it's up to you how you attack this part.


Next we need to set up the Group Policy Preferences. We will create a single GPO and add three sets of preferences to User Configuration | Preferences | Windows Settings | Registry, one for each of our PDF readers.




Each preference item points to the same Registry value (the one from the GPO) - HKLM\Software\Policies\Microsoft\Windows\System\DefaultAssociationsConfiguration - but writes a different value, each of which corresponds to a different XML file. Below is the one for Adobe Reader


As we are writing to an HKLM key, the "Run in logged-on user's security context" option must be unchecked


And finally we will use Item-Level Targeting to direct the Preference item to a specific user-based condition. In this example, we've used the user's OU, but you can use any user-based condition you deem necessary (or combination of such, should you desire)


Finally, we link our new GPO with the Preference items to the XenApp server OU, and ensure that we also have a GPO that enables Loopback Policy Processing so that user items can be executed in the machine context


And then it's time to test.

In my lab, this worked very well, even with multiple users logged in to the same system at the same time. It seems apparent that the HKLM value is read at logon time and then applied to the HKCU area as stipulated in the XML file. Each set of users from each OU could access the configured PDF reader when double-clicking on a common PDF file on their desktop.

If you wanted just to set the default file association at first logon and then roam the user's preference from XenApp server to XenApp server, this is a little more tricky. The Hash value we mentioned in the UserChoice key is unique to the system it was generated on. However, this is unlikely to be an issue except in non-persistent VDI environments, as this form of "enforced" FTA is normally a product of licensing restrictions rather than user selection. I will, though, be looking at the roaming of these settings as part of a future update to this article.

Summary

It's getting like Groundhog Day with Microsoft. We had the whole IE10 debacle that they seem to have backtracked and fixed somewhat (update to the articles coming soon! I promise!), but this is again a case of something that worked perfectly adequately being unnecessarily broken.

The whole idea of having to set an HKLM key which then is read into HKCU is utterly backward. Why can't we just have an HKCU setting or User Configuration GPO to manage this? Although this method works, I can't help but think that a logon storm to a XenApp server, with all the XML file paths being written, read and committed from the same HKLM value at the same time, could potentially cause some issues. Add to this the fact that the XML files have to be maintained locally, and you get the feeling that you just took a load of backward steps from a management perspective. The old "Folder Options Open With" in GPP worked absolutely fine. Why change it? Some have speculated that it's something to do with the Modern interface and FTAs that can cross both application areas, others that it's a security setting - but I think it's just completely stupid. At the very least, give admins a way to manage it. Microsoft do have a product called Remote Desktop Session Host, last I checked, and you'd think they'd want people to use it.
↧
Search

FSLogix first look #2 - FSLogix Apps and Citrix XenApp working together

July 14, 2015, 6:38 am
$
0
0
So, we had our initial look at FSLogix from a Java remediation standpoint, and it seemed to generate quite a bit of interest. However, let's now concentrate on the core product of FSLogix, which is FSLogix Apps, and see the benefits that this brings to those of us with diverse application environments and user bases.



FSLogix Apps is a disruptive technology which almost flips the whole application virtualization ecosystem on its head. Rather than spend time and resource virtualizing applications - whether through traditional app-virt tech like App-V or ThinApp, or newer layering solutions such as AppVolumes and UniDesk - FSLogix allows you to install all applications into the base image and simply "reveal" them to users depending on their entitlements. If you followed my first article on FSLogix, you will know that it isn't just shortcuts and entry points to the applications which are hidden - the entire Registry, filesystem, drivers, services and everything else associated with the application will essentially behave as if it isn't there. No chance of application conflicts, because as far the user running the applications is concerned, the other applications simply aren't there at all. Let's also not forget that applications which are natively installed run faster and more reliably, and that you don't have to spend lots of time virtualizing stuff like device drivers and services because they simply run directly on the operating system. Like everything about FSLogix, the principle behind the FSLogix Apps product is simple, easy and elegant.

We're going to demonstrate this on a Citrix XenApp 7.6 platform to show the value not just for "regular" environments but also virtualized ones. In the XenApp environment, the first benefit you will notice is that image management almost becomes a thing of the past - there's no need for the "image sprawl" that I've seen in so many environments that makes day-to-day support and maintenance incredibly difficult. But even though XenApp and FSLogix seem almost perfectly-suited (particularly in chaotic PVS systems), this isn't just a solution for provisioned Citrix environments - it will deliver the same functionality quite happily to physical machines, VDI instances, standard RDSH, in fact just about anything where there are Windows applications running on a Windows operating system. The possibilities are quite wide-ranging indeed!

For purposes of this demonstration, let's assume we've got a standard Windows Server 2012 R2 image with XenApp 7.6 installed. Rather than publish applications through Citrix directly, the idea is we will present our users with full XenApp published desktops and then use FSLogix to filter the applications available to each set of users. In the interests of keeping this simple, we're going to divide our users into three groups and supply each of them with a specific PDF reader application.

Desktop 1 - Adobe Reader
Desktop 2 - SumatraPDF Reader
Desktop 3 - FoxIT Reader

All of the applications will be physically installed onto the XenApp server, but the FSLogix filter driver will reveal the required application sets based around the user's AD group memberships. So the first thing I need to do is get all of these applications installed into the XenApp server base image.


Once we've done this, we need to install FSLogix Apps and the FSLogix Apps Rules Editor. The beauty again in FSLogix is that it doesn't try to overwhelm you with deployment options of its own - you can leverage existing technologies, for example maybe SCCM and Group Policy Preferences to get the deployment done. I will cover deployment and updates of the FSLogix software and rules in a future article. For the moment, we will just install them the traditional way. They're very lightweight technologies - a single agent that runs as a service, and a console (that could be installed remotely, it doesn't need to be on the XenApp system).


Now we can get to work setting up some rules for our separate desktops. But first, let's publish a Citrix XenApp desktop so we can see precisely what the user would see without FSLogix in the mix. We will configure the Delivery Group to host published desktops only and then launch the desktop through the Storefront web site.

All application shortcuts are showing....

...and we can see admin tools...normally we need to hide these via policies


And we've also created custom desktop shortcuts to the apps, which we'll also hide

As we can see, and exactly as we'd expect, the user has access to everything that we've installed into the XenApp base image. Including all the admin tools such as Citrix Studio and the like, and we're going to use FSLogix to hide these too, as well as the desktop shortcuts that we've created ourselves.

So now let's set up some FSLogix Apps rules through the Editor to change this. Firstly, though, we need to create a bunch of Active Directory objects to apply the rules to. I'm going to do it using OUs (directory containers), because a user can only be a member of one OU at a time. However, if you wanted the option of multiple memberships, you could simply use AD security groups instead - both are perfectly viable options (as are usernames, process names, computer groups, etc.)



So now we can get on and create the rules. Firstly, we create a new rule called Adobe Reader


The FSLogix interface seems a bit backward here. The Rule I am creating is intended to show Adobe Reader to the configured users, but to achieve this you have to create Hiding Rules for the other two applications. I know there probably isn't a way to present them as "Reveal" rules in the interface, but it just seems more logical to me done like this. Maybe it's just me though :-)

So what we will do is create a Rule to present Adobe Reader, and in this rule will be Hiding Rules for both FoxIT and SumatraPDF.


Use the Scan button to scan the installed application and automatically detect files, Registry values and shortcuts associated with it.

When that's finished, click the "Add another application" button


And choose the second application we want to hide, in this case SumatraPDF, and scan that application also.



At this stage, click OK, and you should be able to review what the scanning tool has discovered about the applications that you want to Hide. As I created shortcuts on the public desktop for these applications, I'm mainly checking that those shortcuts have also been discovered (see below - they have)



Next we need to Assign the rule to a our target audience. As we mentioned earlier, we created three OUs and the users in each are going to get a specific PDF reader. So we click on the Manage Assignments button (or right-click the Rule and choose Manage Assignments)

You will see by default the Everyone group has the Rule not applied



FSLogix rules are evaluated from the top down, so here's a quick excerpt from the manual to remind us how they operate

When adding user and group assignments, pay close attention to the order in which assignments are listed.

Assignments are processed from top to bottom. For example, if two assignments were listed, the first specifying "Everyone" with "Rule Set does apply" and the second one specifying "User1" with "Rule Set does not apply", then the Rule Set would apply to Everyone except User1. If these two specifications were simply reversed with "User1" with "Rule Set does not apply" being first, then the Rule Set would apply to Everyone.


It is important to note that a user's group membership list is calculated at log on and will remain the same while that user is logged on. This means that changing what is visible to a user by manipulating their group membership requires the user to log off and then back on again in order for the changes to be seen. This is not the case for changes in the Rule Files. Those changes are immediately active upon distribution of the Rule File.

With this in mind, we will leave the Everyone "not applied" Rule at the top and apply a separate rule for our OU underneath, meaning that only a user in the OU specified will have the rule applied to them.

Click on the Add button to add a new assignment, in this case I choose Directory Container, but as you can see there are quite a few different assignment conditions to choose from.



There is a browse button attached to the dialog box for the AD Distinguished Name, but this seems to be a bit buggy, in that it won't let me drill down more than three levels. No matter - we can simply add the required OU in the path for the AD DN, but this could probably do with sorting out. Anyway, we should now have Assignments looking something like this for the Rule




Next we can create matching rules for the groups that will apply FoxIT Reader and SumatraPDF to the OUs for Desktop2 and Desktop3. This is quite straightforward and only takes a few minutes.



Now that we've got these done, we're also going to create a rule to hide the Citrix admin tools from all users except Administrators. This is a custom rule, so you choose New Rule but select Blank Rule Set from the dialog


And then you can simply right-click on the right-hand side, choose New Rule, and add a Hiding Rule that picks up the directory you want to conceal (see below)



The CitrixTools rule we will apply to everyone except Administrators, so that no-one gets to see these shortcuts except admins, so the Assignments we have created as below


Now we've got all our Rules set up, the final piece we need to put into place are some file type associations (FTAs), so that each user automatically has the application associated with the PDF file type. Regular readers of my blog can now see where yesterday's post originated, so rather than dwelling on this again we will simply use Group Policy Preferences and Item-Level Targeting to push out a file type association based around the OU of the user logging on, which matches nicely with the way we've deployed the FSLogix Rules. If you need to set this up, please reference yesterday's article for this!


And all that's left to do is copy the Rule files into the required folder. I love this bit about FSLogix - it's just so simple. In this case, I just copy the files from %USERPROFILE%\My Documents\FSLogix Rule Sets to %PROGRAMFILES%\FSLogix\Apps\Rules and they are all instantly deployed and active. You can imagine how simple this is to automate as well, even at scale.

OK, we've got it all set up. Let's log on a user from the Desktop1 OU (which should just show Adobe Reader and the associated FTA, as well as no Citrix admin tools). We've bunged a PDF file onto the public desktop so we can easily see whether things are working as intended.

You can see the other shortcuts are hidden and the FTA deployed
And compared to the earlier screenshot, the other PDF readers and admin tools are gone
And in the filesystem, the other entries are simply gone...

You get the picture - I won't bother delving into the Registry as well, those entries will also all be gone. Software that just works breeds confidence :-)

So now let's log on (while the current user is logged in, to give it the normal XenApp multi-session experience) as a user in the OU for Desktop2, which should allow them to see SumatraPDF as the PDF reader software.



Wow! That seemed to work beautifully - our second user is happily assigned SumatraPDF for his use, and he isn't even aware that Adobe Reader or FoxIT are installed on the system. In fact, effectively, as far as his session is concerned, they don't exist on there - even though in another session on the same XenApp server, another user is running Adobe Reader.

So let's log on with a user from the OU for Desktop3, who should be assigned FoxIT Reader as his PDF viewing application.



Clean as you like - the third user on the server can only see FoxIT Reader, and only use FoxIT Reader.

I have to say I am mighty impressed by this, it's dead easy to deploy and manage, and we can direct users to sets of applications based around the context they're operating in without much fuss. As all the applications are actually natively installed, they will run cleaner and more efficiently than if they were packaged, sequenced, siloed, cloud-hosted or any one of the many ways you can deliver apps these days. And those environments with the images upon images that are frankly a blight on a lot of XenApp deployments these days - you can kiss all that goodbye.

You may be thinking about base image bloat, but FSLogix can also mount applications as VHDs to avoid this, effectively redirecting the applications onto the network or a secondary drive to become what FSLogix call "app containers". All in all, it's an elegant solution and one that I feel has a lot of mileage. However, as I said in my previous post, the interface could do with a lot of tidying up and making a bit more logical, but those are cosmetic improvements and I'm sure they will be on the roadmap.

So that covers the base core functionality of FSLogix - filtering application sets based around configurable parameters. We've already looked at it doing Java remediation, but in future I intend to take a closer look at app containers, profile containers and vulnerability mitigation - but not before I get back to some AppSense stuff over the rest of this week. Stay tuned for more EUC fun!
↧
↧

Happy Systems Administrator Appreciation Day!

July 31, 2015, 9:43 am
$
0
0
Well, let's take the AppSense Bigot today where it hasn't been before - a bit of technical comedy. I used to be a Systems Administrator, and even as an EUC consultant I'm always thinking of those poor systems administrators as well as the users. When I put a system in, it hasn't just got to do what the users want it to, it has to be palatable to their long-suffering systems administrators too. So as today, Friday 31 July, is Systems Administrator Appreciation Day, let's celebrate those guys out there doing all the unappreciated donkey work :-)

Yes, it is SysAdmin Day! Today is the one day of the year where all you office workers out there should appreciate, reward and cherish those poor unfortunate souls who run your networks and I.T. systems. You know, the people who ensure that you can always forward emails of rubbish jokes to your friends, who make certain that we pay for precious bandwidth so you can watch streaming videos on the internet, keep your libraries of cat pictures safe and secure, and who generally exist to serve your every electronic whim.

For all you people out there who've never heard of your systems administrator, or who don't realise who they are, here's a little guide to their likes, dislikes, etiquette and behaviour.


1. Systems administrators love their users. Each and every one, with a passion. If you hear us mentioning phrases like luser, I.D.-ten-T, PEBKAC or RTFM, rest assured that these are all very important technical terms and not insults at all. Come and feel our love!

2. We don't resent the fact that people who get paid £20k a year more than us - yes, systems administrators know everything about you - come into our office and demand to know why their photocopier isn't copying, when in fact, they have an HP1505N, which doesn't have a copy function.

3. We like you to get involved and to use the knowledge you have collected from forums, bulletin boards, computer magazines and TV programmes to tell us how to do our jobs better. The fact that we have MCSEs, VCPs, CCNAs and other worthless, waste-of-time computer qualifications doesn't come in to this equation. We always enjoy constructive input from joiners and plumbers about how we should set up Active Directory (Dangerous Brian, this means you!). More please!

4. The fact that you have to change your password every month, and use various different characters in it, isn't security-related at all. It's a game played by system administrators the world over to see how much we can p*ss off our long-suffering users. We spend most of every day conspiratorially thinking of new ways to annoy the people we provide services to by making them jump through hoops to get their jobs done. In reality, we could probably allow everyone access to everyone else's applications, data, documents and mail and just trust you all to play nicely, and we definitely can stretch our budget to include unlimited licenses for every piece of software we own. We just don't like to do it. Not that we don't love you - see #1 - it's just that we're a mischievous, wicked bunch.

5. There is really no need to reboot servers at all. As in #4, we just like doing it, and we get the added bonus of annoying you. We are all addicted to watching Windows Server boot screens flash by. We especially like doing it out of working hours, because we don't have wives/husbands/partners, children, or any sort of lives whatsoever. We live for the restart!

6. We know everything about all electrical devices, the world over. Mobile phones, air conditioning units, TV remote controls, vibrators - they are all the preserve of your system administrator. We also don't mind you asking us about them and expecting a response when the Exchange server is blue-screening. Or during our lunch.

7. We feel an extra-special love for those users who continually demand to know what the exact problem is and then complain because we reply in technical terminology. The time we spend trying to put it into layman's terms could definitely not be better used fixing the problem instead of explaining it to you. When your icons don't appear because of some registry corruption in the software hive of the mandatory profile that we use, there is an easier way to put it. We just prefer to talk in technical terms because it makes up for the sad emptiness of our lives.

8. Less is more. The less information you provide about a problem, the more of a challenge it is for us to fix it. We love challenges, because we don't have a lot to do. We love it when you log cases that simply say "system not responding". That's the ultimate challenge and we get an adrenalin rush when we see it.

9. WebSense and other internet filtering / monitoring tools are utterly pointless. We only purchased them to get you wound up, because we weren't having enough fun with #4. It also makes us feel powerful. After all, the Internet is completely safe.

10. And don't forget - your problem is always more important than anyone else's. Even if seven hundred other people can't log in to their machines, the fact that Microsoft Word has defaulted to English U.S. is definitely much higher on the urgency scale. If we seem to have ignored this fact and are set on dealing with other issues first, always remember to come out with one of those lines we always love to hear, like "This is stopping me from doing my job" (despite the fact you've been doing it for months with the problem anyway), or "This is just not good enough". Alternatively you could send us a snotty email and make a point of CC'ing about eighteen senior managers. Those sort of constructive reactions make us go all warm and fuzzy inside, and will no doubt make us drop everything and sort you out there and then.


Ah yes, the trials and tribulations of managing computer systems. It wasn't always like this. I think the corporate juggernaut that is Microsoft might just have to bear some of the blame for all the anger that we sometimes feel. They've made computers so user-friendly that any idiot can try to operate one. Back in the days when I managed Novell Netware systems with our primary application running on AS/400, users didn't dare mess with stuff. It was all scary, command-line voodoo magic. Now our back-end servers all run Windows, with point-and-click interfaces that users find peacefully reminiscent of their PCs at home. (Oooh! What does this do?) I'm glad that Linux back-end systems are having something of a renaissance with virtual appliances - they, at least for the moment, have still got that intimidating command-line don't-mess-with-me presence about them.

The Fisher Price-friendliness of Microsoft's products also ensures we have to work with some utter dodos, who for reasons only known to themselves have made it into the I.T. industry. The saying about "a little knowledge being more dangerous than none" never rings truer. I once had a field service guy call me up and tell me that the backup was failing on Fridays because the Friday tape was stacked vertically instead of horizontally. There was an MCSE-qualified engineer who asked me how to format a floppy disk. And another desktop guy who was doing a server rebuild who built me an NT4 PDC instead of a BDC and brought it online with the same domain name. And the idiot who built a test VMWare DHCP server and connected it to our live network. The list goes on and on.

Little wonder the poor SysAdmins get so little respect, what with buffoons like those. It doesn't help that our entire user base thinks of us as real-life versions of the Comic Book Guy from The Simpsons, who spend our working lives writing shell scripts and eating junk food, and our home lives in Internet chat rooms and playing World of Warcraft. On the other hand, even if we are sterling non-geeks, there's still no way we'd be as cool as the hackers from Swordfish.

Which leads me inexorably onwards to another rant-worthy subject. Why are computers so misrepresented by Hollywood producers and the makers of TV programmes? (I know I'm about to sound really nerdy here, despite my vehement rejections of nerdiness, but so what, it's SysAdmin Day and I can do what I want). For starters, they always use Macs instead of PCs, probably for their better visual effects, but it still doesn't make out as particularly realistic. And I sure as hell wish they'd do their homework a bit better! I managed to spot an invalid IPv4 address in The Net with Sandra Bullock, which, let's face it, is simply a schoolboy error. I picked up on Jordi LaForge's reference to "subroutines" in Star Trek - The Next Generation (come on! What's the Enterprise written in, BASIC?). I'm still at a loss to explain how Jeff Goldblum in Independence Day was stuck working as a cable repair guy, because the virus he knocked up in a couple of hours (with a hangover, I might add) to run on and completely crash an unknown network of alien operating systems, was absolutely mind-blowing. Mind you, those aliens want to have a serious look at their I.T. security strategy. Their firewall admins should have been sacked aeons ago, and as for their antivirus, they were clearly using Symantec Endpoint Protection.

Mind if we're talking screen-based computing, the conundrum I really want to know the answer to is what is the software they use down in CSI? You know, the kind that can take a photo and pick the reflection of a killer's face out of the eyeball of some guy standing four hundred yards away from the photographer. The same image-enhancement package also carries a geometric mapping module that can triangulate the position of a sniper using the shadow of a hot-dog stand from a video taken outside the building the gunman fired from. I don't have any idea what it is, but it sure isn't Adobe PhotoShop.

In fact, the only film ever to do a realistic computer scene has to be The Matrix Reloaded. Trinity manages to hack into some facility using (IIRC) the open-source tool Nmap and an old Linux exploit. It has to be said, though, if they'd been using Windows Server, there's a good chance that the hole would have been patched by Automatic Updates. How come is it every important computer system in films is always a "mainframe"? I'm surprised Microsoft haven't sued Hollywood for misrepresentation. From Mission: Impossible to Goldeneye, all the vital systems with the most sensitive data are great big whopping digital-UNIX-based "mainframe" servers. Not a Windows-based blade in sight.

Ok, ok. We are a bit geeky, I'll admit. But cut us a break, if only for today. It's tough being a systems administrator (yes, I can hear the violins playing). We're the only corporate service where perfection would be thought of as being the norm. And then when we do achieve perfection, people start wondering why we need so many staff. We just can't win.

So all you non-system-admins out there - spare a thought for your long-suffering I.T. staff on SysAdmin Day. Take them a box of cream cakes and think about all the work behind the scenes they do that keeps those emails from your Facebook pals flooding in and making your working day more bearable. We aren't all browsing the Internet under the pretence of "code compiling" - those guys are called developers.

And all the System Admins in the world - I salute you. Whether we are tearing our hair out at the latest round of patches that Microsoft have released out-of-band, cursing our user base for opening email attachments, or simply trying to keep our lives as stress-free as possible, we are the troopers that keep the wheels of industry turning. Because as we all know, if our CEO couldn't play Flash games on his PC, the world would fall apart.

↧

Windows 10 part #1 - first impressions on roaming capabilities...nice face, rotten heart

August 10, 2015, 4:08 am
$
0
0
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.
↧

QuickPost - Windows 10 part #2 - getting rid of OneDrive

August 12, 2015, 12:39 pm
$
0
0
Many of us have already adopted Enterprise File Sharing and Synchronization (EFSS) products. Many abound in the EUC space - ShareFile, DropBox, DataNow, Hightail, Box, to name just a few. Microsoft are aggressively marketing their own version - OneDrive, renamed from SkyDrive, presumably under pressure from real-life Bond villain Rupert Murdoch - and this aggressive stance has increased with the advent of Windows 10. If you've already got an EFSS solution integrated and working nicely, how do you get rid of the OneDrive integration so that your users don't get confused and/or frustrated?

Microsoft appear to (for once) be quite understanding of this possible situation, and have provided Group Policy Objects to deal with this. Actually, there's been a SkyDrive (later updated to OneDrive) GPO present for Windows 8.1/Server 2012 R2 for quite a while. The relevant settings are tucked away in Computer Configuration | Admin Templates | Windows Components | OneDrive.


The pertinent setting is the one highlighted above - Prevent the usage of OneDrive for file storage. According to the blurb, set this and you lose the OneDrive app, the link to it in the notification area, the Explorer integration and all of the other entry points to it (see below for some of the ones you may notice).




However, if we enable the GPO setting we mentioned earlier, we notice something strange - despite the fact that GPResult reports the GPO as being applied, all of the entry points are still there, which is rather odd.



Digging further into the GPO we are using reveals that perhaps the setting we are using only applies to Windows 8.1. A TechNet article has this telling quote:-

OneDrive Group Policies are only available through a Windows 2012 R2 domain controller to Windows 8.1 clients.

Is it possible that we're still waiting for the setting to be made available on an enterprise basis with the promised Windows 10 RSAT and ADMX file update that's supposed to be coming soon?

Further credence is lent to this theory by the way we can access the settings - and make them work - by firing up the local Group Policy Editor (gpedit.msc) on the Windows 10 endpoint and setting them this way.


But until the new RSAT and other tools for the enterprise come along, how can we deploy this to multiple endpoints in the meantime? Well, the easy way would be to set the policy through the local Group Policy Editor and use Process Monitor to capture the Registry value it sets. A quick ProcMon later, and we find this setting being the one changed by the mmc.exe process

HKLM\Software\Policies\Microsoft\Windows\OneDrive
DisableFileSyncNGSC
DWORD 1

Group Policy Preferences, anyone (or AppSense EM - I keep forgetting that, for the moment at least, I am still the AppSense Bigot)?


A quick bit of replication later, and we should be able to log on to our Windows 10 machine and have another look.


Cool - it is gone from Explorer and the notification area. If you've got a profile already stored on the endpoint before the Registry value was set, you may still see a OneDrive shortcut on All Apps, but it will be dead - click on it and nothing happens.

So that's it for a quick rundown on getting rid of OneDrive for your enterprise users should you need to, at least until the proper GPOs and RSAT for Windows 10 are updated. It's a bit annoying, though, that the setting looks destined to dwell in Computer Configuration - I would have much preferred to be able to switch off the access to it on a per-user basis, especially in RDS environments, but this being Microsoft we should be pleased we get any management capability at all these days.
↧
↧

Roaming Citrix management consoles through AppSense Personalization Server

August 20, 2015, 7:29 am
$
0
0
I remember quite a while ago I was asked by a client of mine to get the Citrix management console running through Personalization Server for them. Management consoles of all sorts have always been (in my experience) a bit fiddly to get running through Personalization Server, so let's have a run-through of what it takes to get this configured.

There are quite a lot of XenApp and XenDesktop versions kicking about at the minute, and anyone who knows Citrix will probably know there are as many different consoles as there are versions of the software. Let's concentrate on a couple of them:-

AppCenter from XenApp 6.5
Citrix Studio from XenDesktop 7.6

We will use AppSense Environment Manager 8 FR 6, the latest version, to grab the Personalization data.

Citrix AppCenter on XenApp 6.5

Let's start with the first one, XenApp 6.5 AppCenter. Seasoned Citrix admins will know that the first thing we have to do (on the old IMA products) is configure the Discovery for the farm


Once we're in and past the Discovery, let's get rid of the right-hand side panel and change the displayed columns for the Servers node



Once we log this user out and back in, as it is using a local profile, the settings should persist as we left them. They do - when we log back on, the Discovery does not need to be run and the customized columns are present. All well and good.

Now let's prep our XenApp server for Personalization and create another Citrix admin with a mandatory profile defined in ADUC.


So, with a normal AppSense EM configuration defined for Personalization, we should be able to try and capture the settings that we need to save. Let's give it a go!

First thing to note is the AppCenter is an mmc.exe process and in pre-8.5 versions of Personalization Server this may appear on the Default Blacklist. However as we are on 8 FR 6 this shouldn't be an issue any more. Firstly, we need to add the mmc.exe process to our list of applications so it is available to be added to an Application Group.



And then, obviously, add this application to the Application Group we have defined (always add applications to Application Groups for management, even if there is just the one). And don't forget to add the Application Group to your Personalization Group (that's the step I always forget, same way I always forget to link a GPO to the relevant OU once I've created it)



So let's see what we can capture up. Firstly, we try synchronizing {CSIDL_APPDATA}\CitrixMMC - will this be enough to work?



Logging back in suggests that it is indeed enough, rather surprisingly, as my changes have successfully held. Coming from a background where I don't trust anything that works first time, let's elect to create a View in My Views and add some items to it, just to make sure everything's working, so let's log out and then back in again...



...and my custom view appears perfectly. So looks like AppCenter works very well with just the following steps:-

mmc.exe added to Personalization
mmc.exe added to AppCenter Application Group
{CSIDL_APPDATA}\CitrixMMC added to Folder Includes for Application Group
AppCenter Application Group linked to required Personalization Group

Looks pretty straightforward...so that was extremely easy, and my apologies to Paul Bonner for whom I promised to look into this for a long time ago (he's actually left the position he was in, so he's unlikely to read this apology, but hey, never say never). Let's hope it's as easy for XenApp 7.6 - let's fire ourselves up a new server!

Citrix Studio on XenApp/XenDesktop 7.6

Now, we've got to log on to a newer Citrix server and run Citrix Studio, which is the latest name for the primary management tool. Studio also runs as part of mmc.exe, which may make things tricky if you want to manage both these consoles for one user, but let's wait and see what transpires.

To be honest Citrix Studio doesn't have that much to customize, but I can imagine getting rid of the "first run" nag screens would be something everyone would want.



You can also save Searches, which we will also customize to see if it roams OK



And as in most Citrix consoles, select the columns we want to display (actually, I'm quite impressed by how many different pieces of information are now available in the latest XenApp/XenDesktop versions)



Now that we've customized it all up again, let's see if we can work out what we need to persist to get these settings brought back when we log in again.

Digging in the %APPDATA%\MMC folder this time reveals a file with the name of StudioSF. Hmmm. There's also an XML document that looks relevant in %LOCALAPPDATA%\Citrix\DesktopStudio, and some pertinent-looking Registry values in HKCU\Software\Citrix\XenDesktop\DesktopStudio. Let's start with these...





...and it looks pretty good, to be fair, once we log in on a different server. Nag screens are gone as expected, custom Search is present and correct - but the selected columns for our Search have reset to the defaults. This is annoying - but not our fault, as a bit of Googling and testing reveals that the column settings don't even persist between launching the application a couple of times, let alone logging on to a different machine and running it from there. That's a missing feature that those in the pubs I frequent would succinctly describe as "a load of f*cking sh*te", and I'm heartily inclined to agree. Imagine being an admin and having to reset your column views every morning for a big Citrix farm - sort it out, Citrix. The fact that we are roaming the column settings successful on XenApp 6.5 (and I can definitely remember it working on XenApp 5 as well) only adds fuel to the fiery crapness that this represents - it's the small things that make all the difference to administrators!

But if you can get past the issue of the column settings, you can successfully roam the other bits through Personalization Server with these steps:-

mmc.exe added to Personalization
mmc.exe added to Citrix Studio Application Group
{CSIDL_APPDATA}\MMC\StudioSF added to File Includes for Application Group
{CSIDL_LOCAL_APPDATA}\Citrix\DesktopStudio added to Folder Includes for Application Group
HKCU\Software\Citrix\XenDesktop\DesktopStudio added to Registry Includes for Application Group
AppCenter Application Group linked to required Personalization Group

Interoperability

The problem you will get with interoperability is if you set both Application Groups individually as above and linked them to the Personalization Group, you'd never be sure which one was actually managing the application - which is why you will get this warning from EM if you add both of these Application Groups to the same Personalization Group.



So the best way to handle a user who might need to access both of these consoles, suitably Personalized, would probably be to create a single "Citrix Consoles" Application Group for mmc.exe and add all of the settings we defined for both groups into it.

Application Group name - whatever you want
Folders - {CSIDL_APPDATA}\CitrixMMC, {CSIDL_LOCAL_APPDATA}\Citrix\DesktopStudio
Files - {CSIDL_APPDATA}\MMC\StudioSF
Registry - HKEY_CURRENT_USER\Software\Citrix\XenDesktop\DesktopStudio

My testing seems to indicate this single-Application Group approach works quite passably but, as always, check and test thoroughly if you need both of these consoles Personalized (although I'm sure most people are aware of this caveat, even though there are some out on the Interwebs that seem to think every article I write is positioned as an absolute technical authority)

Summary

So, in summary, not as much of a chew on as I anticipated to roam the console settings from what are probably the two most prevalent Citrix management tools at the moment. If you're still using the Delivery Services Console, Access Management Console or (God forbid) the Presentation Server Console, then feel free to drop me a line if you're having any trouble Personalizing them - but beyond MPS 4.5, you may have to send me the source files :-)

But a big thumbs-down to Citrix for not having the ability to roam the column selection settings in Citrix Studio - not even between application launches in the same logged-on session! I'd like to see this addressed as soon as possible - I can only imagine it being a source of extreme frustration for Citrix admins the world over.
↧

Upgrading AppSense DesktopNow - a step-by-step guide

September 23, 2014, 3:44 am
$
0
0
I've never really written an article based around an AppSense upgrade - they have always been fairly straightforward for me. However, given that EM 8 FR 5 offers a few radical changes, particularly on the Personalization Server end, now might be a good time to do a quick run-through of how an upgrade is done, as many more may be considering doing an upgrade to take advantage of the new features.

This guide refers to a full upgrade of DesktopNow - all the components, including Personalization Server. If you're just doing Environment Manager, Application Manager, Management Center, Performance Manager or any combination of these components, the steps will be simplified somewhat. Performance Manager and Application Manager are mainly quite straightforward, as they normally don't involve database work. Environment Manager and Management Center invariably require database updates and updates for the Personalization/Management web services, so they're a bit more complicated. Please ensure that you know how much you are actually going to be upgrading - this runs nicely into my first point below :-)


Know your existing environment

Ensure that you've got a good overview of what your current environment holds and what is to be upgraded. You may need to pay attention to things such as:

  • Are you using load balancing for Management Server/Personalization Server?
  • How many Management/Personalization Servers do you have?
  • What sort of authentication is used?
  • Are you using the Config Assistant, Environment Manager Tools, or the EM Browser Interface?
  • How many instances of the AppSense consoles are installed in your environment?

Preparation

Naturally, preparing and planning is key. What do we need to do prior to the upgrade?

1.  Back up your SQL databases

Obviously the most important part - as long as you have an SQL backup you should avoid any utter disasters. However, this leads us nicely on to point #2, which is one people often forget...

2.  Test the validity of your SQL backup

...does the backup actually work? You need to be sure that it's going to bail you out in your hour of need. Why not do a test restore to a separate database and then spin up a quick VM to test that it's working correctly? You can never be too paranoid in the IT world.

3.  Take some snapshots of your servers

If they're VMs (and most of the world runs their servers virtualized these days, unless they're shouldering enormous loads), then there's no excuse not to give yourself server-level as well as database-level backup coverage by taking some snapshots.

4.  Export agents and configuration files

You can easily save your configurations by exporting them from the Packages tab in the Management Center using the "Export Configuration" command, or even by using "Save As" or "Export configuration as MSI" options from the relevant console. AppSense support recommend doing them as MSI files rather than .a*mp files, but the choice is yours. You can also take copies of the latest agents by simply copying them from the original source files.

The reason for this is because if a configuration or agent becomes corrupted or damaged during the upgrade, you can simply re-add it from the backup files rather than initiating a complete rollback of the SQL database. Of course, there may be those who think any oddness in an upgrade process should immediately be countered with a full rollback - the choice is yours as to how you would proceed in such a situation.

5.  Export Personalization Server configuration to an XML file

Next, export your Personalization Server configuration (all of it) to an XML file. Again, if we lose something specific to the Personalization Server side of things (maybe a Personalization or Application Group), then we can import it back in using the functionality provided by the XML file. Also, it can help to have a reference to check whether all of the settings (like Session Data) have been migrated successfully.

6.  Disable the installation settings for your Deployment Groups

To avoid erroneously sending out updated configurations or agents before you're all set and ready, I find it prudent to set the installation schedules (for both configs and agents) to Disabled on all of your Deployment Groups at this stage. You will need to verify the process by which new agents and configs are pushed out before going "full auto", so it's sensible to do this. If you're not using Management Center to deploy agents and configs, then disable whatever method you're using (SCCM, Altiris, LANDesk, etc.)

7.  Log a proactive support case

If things go heavily belly-up, you will possibly need to invoke AppSense support to help you. To this end, log a case prior to the upgrade and provide them as much detail as possible. Run the support script and upload the results, send them a PSExport (you can request this tool or download it from AppSense Exchange), provide them with information on your infrastructure topology - as much info as possible, really. If the poop comes into contact with the cooling device, then you may not want to waste time gathering information for them when they could be helping put out the fires already.

8.  Check TechNotes and Release Notes

Check the AppSense KnowledgeBase on www.myappsense.com (filter by version may help here) to ensure there aren't any known issues for the version you are upgrading to. Also check the Release Notes supplied with the software. For instance, EM 8 FR 5 has a known issue with Outlook Signatures - see TechNote https://www.myappsense.com/Knowledgebase/TN-151170.aspx

Pre-requisites

Next you will need to get some other pre-requisites in place. Ensure that you run through this next list and make sure there's nothing you're unaware of.

1.  Service accounts

Make sure you know the  account details for all of the AppSense services (possibly a config account, comms account, maybe even a load balancing account). Ensure that the account used to actually upgrade the database has the rights to perform the update (check with your SQL DBA, if, like me, SQL is something of a dark art to you).

2.  Database name and instance

This may sound stupid, but make sure you know these, too.

3.  Source files

Again, possibly a bit patronizing, but make sure you've downloaded, extracted and made available the correct version of the DesktopNow software bundle.

4.  Replication

You will need to disable SQL replication if it is in use prior to commencing, and reinstate it afterwards.

5.  Take the Personalization Server(s) offline

It's recommended to stop users accessing the Personalization Servers whilst an upgrade is in process. Unfortunately, there's really no straightforward way of doing this, unless you decide to disconnect the network connectivity of the server whilst doing the upgrade - and even then, unless you've got an SQL instance running on the same system, you will need to turn it back on to configure the database connection. Stopping IIS will work - but it needs to be running when the Personalization Server software is installed, so it can't be left off for the duration. If anyone's got a way of doing this I've overlooked, please feel free to bang it in the comments section and I will update.

Upgrade process

Now, it's down to the nitty-gritty of the process itself. There are a lot of moving parts in an AppSense upgrade, so if you're not particularly familiar with them, they can be a little bit daunting. This is by no means an official guide - it's just a tried-and-tested way of doing them I've found that's served me well in the past. If you've got something to add - please put it in the comments.

It's important from an upgrade point of view that you understand fully the relationship between the clients, web services and databases. I know most reading this will obviously understand this correctly, but just in case there are any first-timers out there, here's a diagram showing the relationship:-


Personalization Servers

I generally start with the Personalization end because if you screw Personalization up, it's infinitely more noticeable to the end users than any failure on the Management Server. The Management Server could go offline for days and all you'd really miss would be the visibility (unless of course you wanted to update your configurations!)

If you've got multiple Personalization Servers, it doesn't really matter what order you do them in. Just do them one at a time rather than together (as the configuration utility can lock up when accessed by multiple processes).

On the first Personalization Server instance:-

  • Run the MSI (and subsequently the MSP file, if you're doing an incremental SP) to upgrade the Personalization Server to the latest RTM version
  • Run the Personalization Server Configuration Utility
  • Upgrade the database schema
  • Correct any variances identified by the Personalization Server Configuration Utility
  • If you're using the EM Browser Interface, run both the MSI (and MSP file, if necessary) to upgrade the existing EM Browser Interface to the latest RTM version
  • Run the EM Browser Interface Configuration Utility (note - if you're upgrading to version 8 FR 5 of Personalization Server, the EM Browser Interface configuration is done by the main Personalization SCU instead, so this step is unnecessary)
  • Correct any variances identified by the EM Browser Interface Configuration Utility (again, unnecessary if going to EM 8 FR 5)

On all other Personalization Server instances:-

  • Run the MSI (and subsequently the MSP file, if you're doing an incremental SP) to install Personalization Server on the additional systems
  • Run the Personalization Server Configuration Utility
  • Attach to the correct database, configure the default web site and the accounts used to connect
  • Correct any variances identified by the Personalization Server Configuration Utility
  • Run both the MSI (and MSP file, if necessary) to install the EM Browser Interface on the additional systems
  • Run the EM Browser Interface Configuration Utility (see caveat about EM 8 FR 5 above)
  • Correct any variances identified by the EM Browser Interface Configuration Utility (see caveat about EM 8 FR 5 above)

Once you've done this, verify that you can connect to the Personalization Server instance by browsing to http(s)://PersonalizationServerName/PersonalizationServer/status.aspx. If you're using a load-balanced solution, obviously test through the load balanced address.

Management Server

As with Personalization, it doesn't matter what order you do your Management Servers in, as long as you do them one at a time.

On the first Management Server:

  • Run the MSI and (if necessary) MSP files to upgrade the Management Server to the latest RTM version
  • Run the Management Server Configuration Utility
  • Upgrade the database schema
  • Correct any variances identified by the Management Server Configuration Utility

On the other Management Servers:

  • Run the MSI and (if necessary) MSP files to upgrade the additional Management Servers to the latest RTM version
  • Run the Management Server Configuration Utility
  • Connect to the correct database
  • Correct any variances identified by the Management Server Configuration Utility

Verify that you can connect to the Management Server by browsing to the following address:

http(s)://ManagementServerName/managementserver/deployment/manifest.aspx. Again, if you're using a load balancer, test by going to the load balanced address.

Consoles

Next, you need to make sure all other instances of your various AppSense consoles (EM, PM, AM and Management Center) are upgraded. The server-end consoles will be done automatically during the upgrade, so it's just any other client-end ones.

You can upgrade the consoles by browsing to http(s)://ManagementServerName/ManagementServer and clicking on the links, by browsing directly to the AppSense source files, or by software deployment tools. All you need to remember is if it is an incremental SP update, run the MSP patch file after you have run the initial MSI file.

Agents

Once the upgrade is done, updated agents will be available in the Management Console for assignment to Deployment Groups. If you've done an incremental MSP update, you may need to import the new agents via the Packages tab in the Management Console to make them available for deployment. If you're using a software deployment tool instead, you will need to grab the source files for the agents and create new packages as required.

At this stage I usually find it prudent to provision some test machines and try a manual installation of the new agents. Start with the Client Communications Agent so that you can verify whether the pre-requisites are installing correctly, then drop all other required agents on there. If this works successfully, move on to deploying the new agents automatically onto a test machine and ensure this process works as expected (e.g. you may want to ensure users aren't confronted by interruptions or multiple restarts).

At this stage, you can start re-enabling the deployment settings that were disabled as part of the upgrade preparation.

Once the new agents are successfully deployed, your clients should be able to function as previously, even if they are still using an older version of the configuration. However, upgrading the configuration is usually done as part of the upgrade process to take advantage of new features and performance enhancements. If you're not upgrading the configuration at this point, you may want to keep an older version of the required consoles available so you can edit the configuration, if necessary.

Configurations

The first time you open an older configuration in a newer console, it will be upgraded to the latest version.


Once it has been upgraded, it can now be assigned to Deployment Groups or software distribution packages as required. When it is upgraded, it must be saved under a new name - this ensures that you can always revert to the last version of the older one if anything stops working or goes wrong. As in the agents section, you may want to test with a manual install first to ensure that everything is working correctly.

Other tasks

Dependent on your environment, you may also need to upgrade and test the following utilities:

Environment Manager Configuration Assistant
Environment Manager Tools

At this point, it would also make sense to apply any fixes or workarounds that have arisen from any known issues you may be aware of from the Preparation stage!

Testing

Testing is, of course, crucial. Every environment is different, as we all have our own application sets and particular requirements that users need to be fulfilled. If you need somewhere to start, here's a quick checklist of things you should be verifying:

  • Logging on without issue or unexpected delays
  • Receiving all expected shortcuts and settings
  • Verify that common applications work OK (Outlook, IE, Adobe Reader, etc.)
  • Verify that common applications have prior Personalization settings (Outlook signatures, Word custom dictionaries, IE Favorites, etc.)
  • Change Personalization settings in common applications, log out and back in, verify that changes to settings are persisting

There will always be something that gets overlooked - that's just life - but being as thorough as possible with the testing phase can ensure that you reduce the pain as much as possible, for both yourself and your users!

Summary

Hopefully this guide should help out those who are doing AppSense upgrades, especially people who are finding that they are doing them for the first time. You should also refer to the AppSense Install and Upgrade guides that come with the source files to ensure that nothing gets missed.

If things do go wrong - and sometimes they do - it's always worth touching base with AppSense support to see if the problems can be rectified before heading for a rollback. Naturally there will be a pressure of time, but it's sometimes handy to see if the upgrade can be salvaged rather than wasting the entire change window. Of course, if you're in any doubt about the integrity of your environment post-upgrade, then a rollback is the only sensible step.

Have fun!
↧

Create Windows mandatory profiles in ten steps (for AppSense DesktopNow, or not, as the case may be)

October 10, 2014, 3:42 am
$
0
0
Deciding on your profile type is an important part of any virtualized deployment, but it is particularly important when deploying AppSense DesktopNow, as AppSense merges user settings into a base profile to create the user environment. The idea is that the local copy of the profile is discarded at logoff - meaning that normally, the options for working with Personalization Server are a mandatory profile, or using a local profile with the "flip to temp" trick (which is made infinitely easier in EM 8 FR5 with the new session variables).

About mandatory profiles

Mandatory profiles have certain restrictions that may or may not hold you back - sometimes specific types of certificates don't work particularly well with them, although there are ways around this (spoofing using the Advanced EM Setting SpoofProfileForWholeSession, for instance). It depends on the applications in use in your environment, really, as to whether local flip-to-temp profiles or mandatory profiles should be used. Some people use a rule of thumb as "mandatory for XenApp, local for VDI", but there is no real right or wrong answer.

I prefer to use mandatory profiles where possible because it's easier (in my opinion) to create a mandatory profile with certain default settings than it is to customize the "Default User" area of your base image and push this out. If you've already got an established estate, then using a mandatory profile may be much easier. But as I said, it depends on how your applications behave, so good testing is, as usual, very necessary.

Citrix UPM uses a unique approach whereby a "template profile" can be defined rather than a "mandatory" one, but adding UPM to the mix just to take advantage of this feature would probably be overkill. It's also worth mentioning that there are now two flavours of mandatory profile - standard mandatory, and "super-mandatory". Super-mandatory profiles work in exactly the same way except users are denied logon if the profile is unavailable (it's essentially the same as configuring a mandatory profile and setting the "Log users off if roaming profile is unavailable" GPO). This is handy for ensuring users can't sidestep any restrictions built into the profile by logging on with a temporary profile.

Storing mandatory profiles

As to where to store the mandatory profile, again this is up to you, but I prefer to keep it local to the system, usually in C:\Users\MandatoryProfile or similar. You can store it on a network share for easy updates, but if the share goes offline you will lose access. An ideal way to get the best of both worlds is to put it on a network share and use an AppSense EM Mirror Folder Action to copy the files to the device at Startup (in EM 8 FR5, Mirror now hides under the Copy Folder Action).

OS Profile types

XP and 2003 used "v1" profiles, whereas 7 and 2008/2008 R2 use "v2" profiles. Later OSes will use .v2 by default, but they will "convert" them first, leading to a drag in logon time. In the interests of keeping logon time down, it is probably best practice to create a mandatory profile for each version you're going to be deploying - this may take a little longer to set up, but you will reap the benefits later.

With a nod to Richard Thompson here, who covered this off in a recent blog post, first you would need to install the following Microsoft hotfix (on the Windows 8/2012 or later machines) to enable specific profile types for each operating system type - https://support2.microsoft.com/kb/2887239

This will mean that each OS version now expects a specific profile type:-

  • Server 2003/Windows XP - v1 profile
  • Server 2008/Server 2008 R2/Vista/Windows 7 - v2 profile
  • Server 2012/Windows 8 - v3 profile
  • Server 2012 R2/Windows 8.1 - v4 profile

(Not sure whether Windows 10 will join the v4 parade or move to v5 - looking at the Tech Preview, I'd definitely suspect a v5!)

So what you'd need to do is create a profile for each under your mandatory profile store, we will use \\Server\Share for the example here

  • \\Server\Share\MandatoryProfile (for XP and 2003)
  • \\Server\Share\MandatoryProfile.v2 (for 2008, 2008 R2, Vista and 7)
  • \\Server\Share\MandatoryProfile.v3 (for 2012 and 8)
  • \\Server\Share\MandatoryProfile.v4 (for 2012 R2 and 8.1)

Then it would be a good time to get creative with our AppSense Mirror command, assuming you're going to follow my lead and copy them to the device at startup (this would be an ideal time to make use of 8.5's Network Available trigger!)


Don't forget to use the flags on the Action to Copy Security Attributes and also the Ownership attributes (see below)


Deployment of mandatory profiles

Mandatory profiles can be defined on the user object in AD (on the Profile tab, RDS Profile tab or both of them, as required) or pushed via a Group Policy Object (for RDS only). Bear in mind, though, that if you define the GPO it is a Computer setting, and will apply to all users logging on to the machine (including Administrators), so if you've over-restricted the base profile, test your admin access. I've also seen people deploy mandatory profiles in a more targeted fashion using scripts to modify the profile settings.

It's also worth mentioning that the path to a mandatory profile is independent of the actual folder path. For instance, if we defined the path in AD or via GPO as "C:\Users\MandatoryProfile", this would actually work for all the profiles described above. This is because dependent on the operating system that the user logs on to, the ".vx" extension will be automatically added as required. So if a user had a mandatory profile path defined as "C:\Users\MandatoryProfile", and they logged on to a Windows 7 machine, the operating system would actually look for the profile in "C:\Users\MandatoryProfile.v2" rather than the specific path. This is very handy and means we can define a single mandatory profile path yet have multiple, OS-dependent profiles available.

Creating a mandatory profile

I've attacked this in a rather backward fashion - discussing the deployment of the profile first and the creation second. However I think it is important to first understand how the profiles work before setting about creating one, so if this post appears a bit back-to-front, my apologies.

When creating one, don't forget to repeat the process for each of the profile types you require, as shown above.

1.  Create the base profile

This is probably the easiest bit - log on to an endpoint of the type you require (for instance, if you were creating a .v1 profile for XP or 2003, either an XP or 2003 endpoint would suffice, you don't need to log on to both) and set the environment as you want it to be. Make sure the user you're using is not an admin, obviously, and then set the desktop up as you want it. You don't need to get gung-ho here - for instance, things like Control Panel items will be controlled through GPOs/EM - just get the look and feel the way you want it. Maybe you want to pin some default items to the Taskbar, change the folder views, lock the Taskbar, mainly cosmetic stuff.

Make sure the user and device don't have any Group Policy Objects or other environmental setup actions (like logon scripts) applying to them, at this stage (Block Inheritance is your friend here). And obviously make sure the user has a local profile, not a roaming one!

2.  Log out and back in, and then out again

At this point I like to log the user out, log them back in, and then out again. This just makes sure all the settings are saved correctly into the profile.

3.  Copy the profile settings to the network location

XP and 2003 still have a Copy command under User Profiles, but it has been removed in later versions of Windows. Never fear - you can simply copy the entire %SYSTEMDRIVE%\Users\username folder across to your network location.

The beauty of the Copy command was that it would automatically set the Registry and filesystem permissions for you, reducing the amount of effort required to get the mandatory profile up and running. So we will have to do this manually in steps #4 and #7. As to why Microsoft removed it - I can only guess they were trying to force people to use automated Windows utilities to produce the modified profile instead. I've heard some rumour that they don't support profiles created without automated MS tools - but I've never had anyone from Microsoft complain about supporting an environment with profiles created in the way described in this post.

4.  Change the Registry permissions

Next you need to make sure the Registry permissions are correct so that all users can read it. Open regedit.exe, click on the HKEY_USERS hive on the left, and select File | Load Hive. Browse to the network share where you copied the files to and select the ntuser.dat file (you may need to select the Show Hidden Files option in Explorer). The ntuser.dat file holds all of the user profile's Registry keys.

The dialog will ask for a name for the key, type anything you want in here. Next expand the HKEY_USERS hive and right-click on the hive you've just loaded (this is where the name comes in handy!) Choose the Permissions option.

Remove the original user from the ACL, and then give the Everyone or Authenticated Users group Modify or Full Control (if you're worried this affects security, you can put NTFS Read permissions on the .dat file itself, but I don't normally consider it an issue). Use the Advanced button to replace the permissions on all child folders with the ones you've defined. You sometimes get an error at this stage about setting subkey permissions - this doesn't seem to affect anything.

5.  Flag the profile

At this point, I generally insert a key or value into the Registry hive so I can tell that it's a mandatory profile, just for troubleshooting purposes (see screenshot). Up to you whether you do this, I find it handy though.


5.  Sanitize the Registry

Now, the Registry will contain lots of references to the user which was used to create the profile - now is the time to dig them out. I generally do a search for the username and also for the user SID (use psgetsid to find it if necessary) and remove all references. Take particular care with the User Shell Folders key, however - rather than remove references to the user (if present) I generally replace them with %userprofile% entries.


Another thing to remove at this stage would be any Policies keys - generally found in HKCU\Software and also in HKCU\Software\Microsoft\Windows\CurrentVersion.

You can also remove any items from the Registry you think shouldn't be there (you will be amazed at the references you find). HKCU\Software\AppDataLow is generally useless, as are references to the likes of Adobe and Google. Be careful, though, that you don't break something by being over-exuberant (although I've been pretty brutal in the past, to be fair, and I've yet to cause an issue).

Once you've done all of this, don't forget to unload the profile by clicking File | Unload Hive with the top-level key selected, otherwise you will lock the profile and no-one will be able to access it. This has happened to me in the past, so be warned, it's easy to do!


I have seen people try to save logon time by inserting various Group Policy Registry values into the mandatory profile. You can adopt this approach if you want, but the logon time you would save (probably milliseconds) has to be balanced against the fact that you'd have to more or less repeat this process if you wanted to edit or remove the settings you put in at this stage. With that in mind, I wouldn't recommend it.

6.  Delete LOG and BLF files

Once you've edited the Registry, look in the share where you've stored the profile and you may find a bunch of files with .LOG and .BLF extensions have appeared. Remove these - they don't appear to have any relevance (I'd be interested to find out why they sometimes appear, however).

7.  Change the filesystem permissions and ownership

You will find that the files in the profile folder also need to have permissions set correctly. Again, change them to an appropriate ACL and remove the original user (if present), then propagate them down the folder structure. You will also need to check that the share permissions are OK.

It is also very important to make sure that the BUILTIN\Administrators group is the owner of the folders and files in the profile, otherwise the profile load will fail. Set the Owner from the Advanced tab and propagate it to all child items.

Finally, make sure that the Authenticated Users group has only Read permissions to the file share where the profile is stored (perform this step once you've finished all the other steps below, otherwise obviously you won't be able to edit anything). Otherwise, you will end up with odd behaviour like the creating user's username getting added to the Windows 8 Start Screen, and other weird occurrences. If you need to make a change to the files and folders in here, add Administrators back in, make the change, then remove the permission for admins again.


If you're using the Mirror Action we showed above to copy this to endpoints, the security permissions and ownership should be preserved correctly. If you're not using EM, make sure that the parent folder for the profile has the correct permissions and ownership, and inheritance is turned on.

8.  Sanitize the filesystem

The files and folders in the profile we've created are mostly extraneous. You can delete the Local and LocalLow folders in the root of AppData straight away. Anything else in there needs to be verified, but I normally get quite aggressive and delete most everything apart from a few things in the AppData\Roaming folder (mainly Pinned Items, Taskbar Items and Start Screen files). I'd recommend being quite aggressive too - but keep a backup copy in case anything behaves oddly.

It's up to you whether you maintain the user shell folders in here like Documents, Desktop, Downloads, etc. If you're using Folder Redirection these should be recreated anyway, but I leave them in as empty folders usually.

9.  Rename the .dat file

Once you've done all of this, rename your ntuser.dat file to ntuser.man to make it mandatory (if you're going super-mandatory, the folder name also needs changing).

This would be a good time to check the size of your mandatory profile. A decent size is usually about 1MB all in, although the Windows 8 profiles seem to be slightly larger. Under 2MB would be a good ballpark figure to aim for, at time of writing.

10. Deploy!

The final step is to populate the user field in ADUC or (if it's RDS), the GPO for mandatory profiles (found in Computer Config | Policies | Admin Templates | Windows Components | Remote Desktop Services | Remote Desktop Session Host | Profiles | Use mandatory profiles on the RD Session Host server).

Now log in as a (different) test user and see if you get the mandatory profile loaded (you can check the profile type from the sysdm.cpl applet, or look for the custom Registry key we inserted earlier). If you've done everything right, hopefully it should be there.

The Event Viewer is usually a good source of information if a profile doesn't load - check the Application log and it should point you in the right direction.


It may seem like a big effort to set up these profiles, but if you get it done right, they probably won't need touching again. In the long run, it's probably worth it :-)
↧
Search

Mapping a WebDAV share as a drive through AppSense DesktopNow Environment Manager

November 24, 2014, 7:37 am
$
0
0
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!
↧
↧

Getting to grips with Windows 8.1 #2 - customizing the Start Screen using DesktopNow

November 27, 2014, 3:46 pm
$
0
0
As I promised a while ago, let's today try to do a bit more on the Windows 8.1 side of things, as I have been spending more time than I've wanted to digging around inside, as C3PO might have said, its busty innards. Naturally, we're going to be leveraging AppSense DesktopNow Environment Manager to help us out with the customization and personalization of the Start Screen and UI, but for those of you who aren't AppSense customers, then the basic principles should remain the same.

Update - thanks to Tom Scase and Simon Bond, I've written up a much easier way to get this working. Whilst the method discussed here remains viable, the method in this post - http://appsensebigot.blogspot.co.uk/2014/12/getting-to-grips-with-windows-81-25.html - is far more robust and would be the recommended way of achieving this end.

Windows 8.x introduced a few major, in-your-face changes to users, so if you're upgrading them to this platform, the first and most noticeable change for them will be the appearance of the Start Screen to greet them. You can turn it off with Windows 8.1 so that they don't see it when they boot in to the desktop, but when they hit the Start "button" or press the Windows key (or even Ctrl-Esc for those of you who remember the days before the Windows key), the Start Screen will be there in all of its supposed glory.


This probably isn't anywhere near what you'd want your users to be presented with in a corporate environment. For the purposes of this experiment, we will assume we want to present them with a default set of settings, such as:

  • Email (Outlook)
  • My Documents shortcut
  • Browser
  • An App-V application (Notepad++, for the purposes of this demo)

What we also want, though - the key part, as far as I am concerned - is to also allow them to customize it for themselves, so they can pin items to their Start Screen as much as they like. This is the clincher - Microsoft provide a GPO called Start Screen Layout (one of the few they have deigned to allow us in Windows 8.x) for setting a default Start Screen layout, but it has some issues. It is set up using PowerShell cmdlets - these are discussed below.

Export-StartLayout is the PowerShell cmdlet you use to export out the desired Start Screen configuration. It can export as a BIN or XML file, but there are caveats around this. When you're using the GPO specified above, you need to use an XML file generated by this cmdlet to provide the source.

Import-StartLayout is the cmdlet that imports it back in, but this a) only works using the BIN file, and b) only imports the settings into the default profile on the machine. It's supposed to be used on mounted WIM images, but it will also work on the current Windows install.

The key thing to take away from this is that the way you deploy your default Start Screen layout will depend on the profile type you are using. If you're using local with flip-to-temp (which leverages the default profile), it will be simpler. If you have a mandatory/default/other profile type in use, then it will be a bit more tricky.

Default/mandatory/other profiles

Now I'm sure you're thinking, by far the easiest way to achieve this for these profile types would be to pin a few items to the Start Screen in the default or mandatory profile, and then enable for Personalization Server. But sometimes you don't have this option - maybe you are migrating existing profiles across, or the default/mandatory profiles have already been sealed and dropped into images or onto network shares, or maybe even you want to be able to edit the default items without recreating the base profile. So we will approach this from the perspective of deploying a default set of shortcuts to the Start Screen without involving editing default or mandatory profiles.

Another situation (which I encountered recently) is that when using SCCM or another build process to create the machine, sometimes all the apps aren't installed at a particular time - they are layered into the build via the task sequence. Creating the default profile in this case with the shortcuts pinned to the Start Screen simply created an unholy mess, because apps were imported that weren't actually installed yet. In this case also, using a separate method to import the default settings is very necessary.

Personalization Server and Microsoft's under-the-hood shenanigans

The other consideration to bear in mind is that Personalization Server, unfortunately, isn't straightforward when it comes to the Start Screen. Remember the mess Microsoft made of Taskbar Pinned Items, with the eclectic (sarcasm) combination of files and binary Registry keys to populate them? The Windows 8.x Start Screen brings more of the same misery, with Microsoft insisting on overwriting Personalized settings with their own default set of garbage at logon time.

A big tip of the hat towards Richard Thompson here, who did a great piece on his blog which we are going to be referencing very heavily here (I believe credit is also due to Richard Bancroft of AppSense Professional Services for his work on this). In fact, the two Richards have done most of the heavy lifting for us, to be fair, and we are simply going to be adding in a few bits to their process.

First things first

Firstly, let's get the default set of items configured the way that we want them. Log on as an ordinary user, and let's remind ourselves again of the rainbow dog-vomit mess Microsoft wants to lumber us with...


Ugh. Honestly, every time I see this screen, I'm just reminded how drastically unsuitable it is for a corporate environment. We've all gotten used to strimming the guff out of Windows operating systems down the years, but Windows 8.x not only succeeds in being so drastically in-your-face about all this crap, it also denies you any enterprise-grade tools to remove it with. Anyway - set your sights and tear it to pieces!

By the time you've finished, you should have something a lot better looking...note we've actually named the Groups on the Start Menu too, this is another setting we will be looking to roam successfully with Personalization Server.



So, we can now drop out to a bit of PowerShell and export this out to a file. Sounds promising! (Thanks to Aaron Parker's blog for pointing me in the right direction of the PowerShell cmdlets required)

Now, this is where we need to start moving in different directions dependent on your profile type.

Exporting the default settings you have created

So obviously, we've logged on with an account and created the default Start Screen layout we want. Next, we need to export these out to a file - this will be done differently dependent on profile type.

Local profile with "flip-to-temp"

Should use

Export-StartLayout -As BIN -Path pathtoyourfile.bin

as shown in the example image below



Other profile type (mandatory, default, etc.)

Should use

Export-StartLayout -As XML -Path pathtoyourfile.xml

as shown in the example image below


Each of these commands will dump the file out to wherever we want it (network share is good, as is a folder that will be maintained on the base image in some way).

Importing in the settings for the user

Once we have the file exported in the required output type, we can set up an AppSense command or Action that is going to import it into the default, template or mandatory profile. Again, which profile type you are using will determine which way you do this.

Local profile with "flip-to-temp"

Because, in this situation, we want to import the settings from the BIN file we exported into the default profile (which will then be used to create the user's profile each time they log on), we need to use a PowerShell cmdlet at Computer | Startup or Computer |  Network Available (dependent on where you stored the BIN file you created, and what version of EM you are running)

The command is this

Import-StartLayout -LayoutPath pathtoyourfile.BIN -MountPath "$env:SYSTEMDRIVE\"

Now, as mentioned earlier, be aware that this command operates on the default profile on the machine. Essentially, we are modifying the Start Screen for the default profile (c:\Users\Default) as the device starts up.

Note that what this cmdlet does, under the hood, is simply bung an appsFolderLayout.BIN file into %SYSTEMDRIVE%\Users\Default\AppData\Local\Microsoft\Windows, so if the path doesn't exist, then the cmdlet will fail. (This one burned me when I tried to be too clever with the default profile!)

This process is shown being done in AppSense EM in the images below

 



Once you've done this, it's time to move onto getting Personalization to work - skip ahead to the section for "Getting the Start Screen to Personalize".

Other profile type (mandatory, default, etc.)

if you're using one of these profile types, importing in a default set of Start Screen tiles is going to be slightly more challenging. I'm using the word "slightly" rather lightly here :-)

In order to import the files into a "pre-existing" profile, we can't use the Import-StartLayout command - as we've said previously, that would simply set to work on the default profile, which obviously isn't used in this case. We can, however, use the Start Screen Layout GPO, which uses the XML file we exported earlier.

The problem is, this GPO locks the Start Screen into read-only mode - meaning we can't edit the Start Screen once we've logged in. Bit of a problem!

To get around the problem with the locked Start Screen, we are going to set the GPO to Enabled early in the logon process (setting up the default Start Screen), and then set it to Disabled later on in the process (allowing the user to change it). Nifty!

So, when the user logs on (we're using the Logon | Pre-Desktop trigger from EM 8 FR 5 here), set the GPO through an EM ADMX Action, and specify the XML file that we created with Export-StartLayout. Note - you will need the Windows 8/Server 2012 GPO files, obviously, so a 2012 R2 DC may come in handy, or some file copying :-)




And then, later on (we are going to add this to the old custom Post-Logon trigger, as it is necessary to resurrect this to get the Start Screen to Personalize - see next section for details) we will apply the same GPO again - except this time reverse it.



This means that when the user is logging in, the default items will be applied. However, because the GPO is then reversed, the lock is removed - allowing Personalization to be layered in, and the user to apply customizations. What you will notice is that there is a slight delay when the user can't right-click on items on the Start Screen just after they log on - but it will allow them to do so after a few seconds/retries. It's not ideal, but given what we have to work with, it's as good as it's going to get! Obviously, though, this will only be at first logon, because if you check the next paragraph, we're going to set a flag to make sure it only runs once.

As I said, we don't want this default layout to be applied every time, that would just cause problems. The idea is for it to apply the first time the user logs in, or if their Personalization is deleted. So we will set a Registry flag value after the GPO is applied the second time, and then it shouldn't run again unless Personalization is deleted - as we are going to save this custom Registry key into the Personalization data too.


The Registry value we're checking for - and will then set

Getting the Start Screen to Personalize - the return of the post-logon trigger?

However....to successfully Personalize Windows 8.1's Start Screen brings with it a requirement that I didn't think I would need again after EM 8 FR 5 shipped - that of the Post-Logon Offload Trigger (that's what I christened it - others may have different terms for it). This is because once you've loaded the Personalized Start Screen, you need to refresh the shortcut files which exist within the {CSIDL_PROGRAMS} folder to get them to display properly. Now, the Desktop Created trigger which arrived in EM 8 FR 5 doesn't run late enough to fulfil this requirement, so, annoyingly, it is back to the Post-Logon Offload Trigger (PLOT), the setup of which is described in detail in this post. Before you get started, set this up - you're going to need it! Note to AppSense - I hope you're building support for this into a Service Pack for EM 8 FR 5, as it looks like pretty poor show to have to bring it back after binning it was a headline feature for the upgrade in the first place. Yes, I thought we'd finally lost the PLOT - but it turns out we haven't. Not by a long way :-)

Once you've got the PLOT set up, you will need to set up your Windows Personalization Group (doing this on EM 8 FR 4 and below will be a bit trickier, but Richard's blog post contains examples for earlier versions too, if you need them). The folders you will need to add into this are:-

{CSIDL_LOCAL_APPDATA}\Microsoft\Windows\appsFolder.itemdata-ms
{CSIDL_LOCAL_APPDATA}\Microsoft\Windows\appsFolder.itemdata-ms.bak
{CSIDL_PROGRAMS}

(The {CSIDL_PROGRAMS} is required to roam any folders that may be pinned to the Start Screen)

As for Registry keys, simply add these:-

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\Grid

(The second entry adds the app sorting type, shown in the screenshot below)


This should leave your Windows Settings Group looking like this, which is then linked to the Windows Personalization Group (I set the Conditions on the Windows Personalization Group rather than the Windows Settings Group)


Don't forget, if you're using the non-local profile method, you will need to add your custom Registry value in here also, to ensure it is saved in the Personalization data!

Now it's over to the two Richards to take it from here! During logon, they will set the attributes on the two files used for the Start Screen - appsFolder.itemdata-ms and appsFolder.itemdata-ms.bak - to Read-Only, so that they can't be arbitrarily overwritten...


Then, once logon has finished and we're into the Post-Logon Offload Trigger, they will unset the Read-Only attribute, so that the files can be Personalized...


And now the real voodoo starts...finally, there is a bit of VBScript that forces the Start Screen to refresh by "tickling" (love that term) the .lnk files in the {CSIDL_PROGRAMS} area. This seems to crack the final bit for us - much credit due to Richard Bancroft for this bit.


My testing seems to indicate that these two methods work, although it's been done in a limited environment (Windows 8.1 VMs against EM 8 FR 5 instance on Hyper-V). The mandatory profile I used in testing was created on a Windows 8.1 machine, so you may see different results using older profile versions - however, as it says in my previous mandatory profiles article, it's best to use the right profile version for the OS you're working with.

OMG! It works (even Personalizing the childish group names)

However - we need a summary, because this has been far too damned complicated and full of problems!

Summary

So, the main part of this article is backing up the excellent work done by Richard and Richard which gave us a way to Personalize the Start Screen correctly. What we were trying to achieve was putting in a default set of Start Screen items for users logging on for the first time, without actually re-editing the default or mandatory profile.

If you're using a default profile (and also probably the flip-to-temp trick):

Use the process provided by Richard and Richard, and simply add a Custom Action to the Computer | Startup/Network Available trigger to run the following command

Import-StartLayout -LayoutPath pathtoyourfile.BIN -MountPath "$env:SYSTEMDRIVE\"

That's all that's required - Richard and Richard's configuration will handle all of the rest.

If you're using a mandatory/super-mandatory/default/other profile:- 

During the Logon | Pre-Desktop trigger, check for the existence of the custom Registry value indicating the Start Screen has been imported. If it doesn't exist, run an Action to set the Start Screen Layout GPO, using the XML file you exported as the template.


During the Post-Logon Offload Trigger (the Process Started for refreshnow.exe, if you're using Richard and Richard's config) check for the existence of the custom Registry value again. If it doesn't exist, run an Action to set the GPO for Start Screen Layout again, this time disabling it. After this, set the custom Registry key so these Actions don't run again.


I apologize for not making a configuration available for download yet (I will add one tomorrow sometime to make things easier). Richard Thompson has one available on his post - hopefully the one I put up should help add some extra features to it. Meanwhile, if you have any problems or questions, please leave a comment or drop me an email - I'd be interested to hear how well this works in the real world.

And with that - thank God that is over! I'm off to bed!
↧

Getting to grips with Windows 8.1 #2.5 - customizing the Start Screen using DesktopNow - the EASY way

December 16, 2014, 8:09 am
$
0
0
Hahaha. Maybe one should always check with others before writing something up, eh?

About two weeks of my life I spent trying to get persistence of the Windows 8.1 Start Screen working, and even at the end, it felt hit and miss. "User profile service failed the logon" and "you have been logged on with a temporary profile" were appearing all too often for my liking. Also, I had somehow, whilst applying the configuration I wrote about in my previous article, managed to stop the Windows 8.1 right-click mini-Start Menu from appearing (God knows how). So after a Twitter-whinge, I was put onto Tom Scase of AppSense Professional Services who had been having a struggle against this problem himself. And I really wish I'd had my Twitter-whinge sooner!

The solution

Tom (and Simon Bond from Ultima) had come across this issue and realized (as I was rapidly starting to believe) that persisting the appsFolder.itemdata-ms and appsFolder.itemdata-ms.bak files from {CSIDL_LOCAL_APPDATA}\Microsoft\Windows was, to put it fairly mildly, unreliable. To the extent that I'd almost started (sorry, Anwarul!) recommending that people don't deploy Windows 8.x in the enterprise - although the lack of proper GPO support and behind-the-scenes changes probably don't mean my perspective on that has altered too much, to be fair.

Anyways - unlike me, who had simply decided to batter his head against these two files until they decided to work (sort of), Tom and Simon decided to go for a much simpler, more elegant solution. Remember the Export-StartLayout PowerShell cmdlet? We used this in the previous article to create a copy of our settings in a .BIN file that could then be imported into the default profile using Import-StartLayout. But the key to what Tom and Simon put together was that if neither of the appsfolder.itemdata-ms* files were present in the user profile at logon, if you placed the appsFolderLayout.BIN file in there, it would expand the .BIN file and create the Start Screen - but most importantly (remember the VBScript in the previous post?) start a refresh.

So - and you are probably starting to realize what they went for now - if you use Export-StartLayout at the Logoff trigger to take a copy of the existing Start Screen settings to a .BIN file, and then saved that into Personalization Server, you could restore the customized settings and trigger the refresh by using Personalization Server alone.

This way works, and it works well. So we are going to cover this post off from the perspective of saving Start Screen settings using this method. But what we will also do is again address the problem we attacked in the previous post, that of setting a default bunch of Start Screen tiles.

We will cover it in two separate sections, obviously dependent on profile type, which we will subdivide neatly into two types from hereon in...

Profile type #1: Local profiles with flip-to-temp, or persistent local profiles (which might be used by laptop/mobile users) 

Profile type #2: Mandatory/super-mandatory/roaming/UPM profiles

Create your default Start Screen

The Start Screen settings we are going to import are:


So, log on as a user, and set up your default settings the way you want them.

Export the default Start Screen to a file

Once you've got it set up the way you want it, now we need to export them out to a BIN file (for profile type 1) or an XML file (for profile type 2).

Profile type 1 - Export-StartLayout -As BIN -Path pathtoyourfile.bin


Profile type 2 - Export-StartLayout -As XML -Path pathtoyourfile.xml




Import the default settings at first user logon

Next we need to make sure that we have the default settings imported in for the user at first logon. Again, how you do this depends on profile type.

Profile type #1

In this situation, we want to import the settings from the BIN file we exported into the default profile (which will then be used to create the user's profile each time they log on), we need to use a PowerShell cmdlet at Computer | Startup or Computer | Network Available (dependent on where you stored the BIN file you created, and what version of EM you are running)

The command is this

Import-StartLayout -LayoutPath pathtoyourfile.BIN -MountPath "$env:SYSTEMDRIVE\"

Now, as mentioned earlier, be aware that this command operates on the default profile on the machine. Essentially, we are modifying the Start Screen for the default profile (c:\Users\Default) as the device starts up.

Note that what this cmdlet does, under the hood, is simply bung an appsFolderLayout.BIN file into %SYSTEMDRIVE%\Users\Default\AppData\Local\Microsoft\Windows, so if the path doesn't exist, then the cmdlet will fail. (This one burned me when I tried to be too clever with the default profile!)

This process is shown being done in AppSense EM in the images below



This is all that's required for this profile type - you can now jump ahead to the Enable For Personalization segment.

Profile type #2

If you're using profile type #2, importing in a default set of Start Screen tiles is going to be slightly more challenging. Now I'm sure you're thinking, why? Because by far the easiest way to achieve this for these profile types would be to pin a few items to the Start Screen in the default or mandatory profile, and then enable for Personalization Server as below. But sometimes you don't have this option - maybe you are migrating existing profiles across, or the default/mandatory profiles have already been sealed and dropped into images or onto network shares, or maybe even you want to be able to edit the default items without recreating the base profile. So we will approach this from the perspective of deploying a default set of shortcuts to the Start Screen without involving editing default or mandatory profiles - but if it's possible, I'd always try using the simpler method!

Another situation (which I encountered recently) is that when using SCCM or another build process to create the machine, sometimes all the apps aren't installed at a particular time - they are layered into the build via the task sequence. Creating the default profile in this case with the shortcuts pinned to the Start Screen simply created an unholy mess, because apps were imported that weren't actually installed yet. In this case also, using a separate method to import the default settings is very necessary.

In order to import the files into a "pre-existing" profile, we can't use the Import-StartLayout command - as we've said previously, that would simply set to work on the default profile, which obviously isn't used in this case. We can, however, use the Start Screen Layout GPO, which uses the XML file we exported earlier.

The problem is, this GPO locks the Start Screen into read-only mode - meaning we can't edit the Start Screen once we've logged in. Bit of a problem!

To get around the problem with the locked Start Screen, we are going to set the GPO to Enabled early in the logon process (setting up the default Start Screen), and then set it to Disabled later on in the process (allowing the user to change it). Nifty! We will combine this with a Registry flag, so that the GPO is only ever exported the first time the user logs in.

The time at which the default Start Screen gets set via this method seems a bit hit-and-miss - sometimes it seems to work OK at Logon | Pre-Desktop, other times it necessitates moving to Logon | Desktop Created. Whichever one we end up using, we will set the GPO through an EM ADMX Action, and specify the XML file that we created with Export-StartLayout. Note - you will need the Windows 8/Server 2012 GPO files, obviously, so a 2012 R2 DC may come in handy, or some file copying :-)

However....to successfully unset the GPO and unlock the Start Screen for customization has to be done at a very particular time. This in turn brings with it a requirement that I didn't think I would need again after EM 8 FR 5 shipped - that of the Post-Logon Offload Trigger (that's what I christened it - others may have different terms for it). Once you've locked the default imported Start Screen, you need to unlock it by reversing the GPO a certain amount of time after the desktop has initialized. Now, the Desktop Created trigger which arrived in EM 8 FR 5 doesn't run late enough to fulfil this requirement, so, annoyingly, it is back to the Post-Logon Offload Trigger (PLOT), the setup of which is described in detail in this post. Before you get started, set this up - you're going to need it!

So, the setup of this part of the configuration (the user getting the default Start Screen at first logon) would look like this (remember this goes in the Logon trigger):



And the second part (which goes in your Post-Logon Trigger, which may be either Process Started or Process Stopped dependent on your inclination) would look like this:



Obviously our Registry flag is set at the end of this, so the default set of icons won't be imported at next logon (unless the users settings were removed, obviously).

This method (setting and then unsetting the GPO) works quite effectively, although if you're lightning fast on the keyboard, you may notice a tiny delay during which you are unable to customize the Start Screen. Any normal user wouldn't notice this - and it will only happen at first logon anyway.

Enable for Personalization

Now, whichever profile type you are using, the method of Personalization is exactly the same (and far simpler than that in the previous post).

Firstly you will need to set up your Windows Settings Group and link it to your Windows Personalization Group. The folders/files you will need to add into this are:-

{CSIDL_LOCAL_APPDATA}\Microsoft\Windows\appsFolderLayout.bin
{CSIDL_PROGRAMS}

Update - according to my Google-fu, you may also need this folder saving as well (although this worked fine for my testing without it)

{CSIDL_LOCAL_APPDATA}\Microsoft\Windows\Caches


(The {CSIDL_PROGRAMS} is required to roam any folders that may be pinned to the Start Screen)

As for Registry keys, simply add these:-

HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\StartPage
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\ImmersiveShell\Grid
HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Explorer\Accent

[also, don't forget to add your custom Registry flag here as well, if you're using a non-local profile]

The first Registry entry above holds Start Screen custom backgrounds, the second one controls the app sorting preference (see image below), and the third one deals with Start Screen custom colours.



This should leave your Windows Settings Group looking something like this, which is then linked to the Windows Personalization Group (I set the Conditions on the Windows Personalization Group rather than the Windows Settings Group)



Finally, we need to put together the necessary Logoff Actions which are responsible for dumping out the Start Screen settings to a BIN file, and then doing a bit of tidy-up afterwards. Tom and Simon found that there were some extraneous settings getting written to HKLM which may cause issues with the Personalization, so we will handily leverage the UserSID variable from EM 8 FR 5 to clean these up nicely!

First of all, in the Logoff trigger, we will set a Custom Action running these two lines of PowerShell (the first one may wrap) 

$ExportFile = $env:localappdata + "\Microsoft\Windows\appsFolderLayout.bin"

Export-StartLayout -As Bin -Path $ExportFile

And underneath this, in a sub-node, we will put the tidy-up Action (removing a Registry key)



The two configurations we have created are available for download below, for each profile type. Don't forget you also need to create the Windows Settings Groups in Personalization Server - the configurations won't cut this on their own! Also, the paths to the export files will need to be set correctly for your environment.

Download configuration for local profile (with or without flip-to-temp)
Download configuration for non-local profile (mandatory, roaming, etc.)

I've also put a node in those configurations that disables the Windows 8.1 first logon animation, which sets the Registry value of EnableFirstLogonAnimation at HKLM\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System, just as an extra bonus :-)

Summary/credits

Well, that's much slicker and better than the previous method I espoused. Especially if you don't need to provide a default set of icons to a user with profile type #2 - if you can get away with putting the default icons into the base profile, then it makes this a much more straightforward (and shorter!) article.

Uber-massive kudos due to Tom Scase and Simon Bond for coming up with this method - simple, but genius. Combine this with the set-unset method for the Start Screen Layout GPO, and we've pretty much got all of our angles covered. I've been testing this for a few days now, and I'm seeing no more of the errors I was being subjected to previously. Obviously Richard Thompson and Richard Bancroft deserve credit to for their original efforts around this again, as they gave an invaluable insight into how much of an absolute abortion Microsoft's processes are in this area (no surprises there). And also a mention to Aaron Parker for his blog piece discussing how to use the BIN file in the PowerShell cmdlets.

Hopefully this should work for those of you with the misfortune to have Windows 8.1 deployments in your AppSense environments. Any questions or comments, please leave them below, or catch me on email/Twitter.
↧

QuickPost - Citrix XenApp published application launches full published desktop?

January 12, 2015, 4:43 am
$
0
0
This burns me on a semi-regular basis, so I'm going to write a quick blog post about it to save me digging the same solution up time and again. So hopefully it should also help some of you out there!

Issue

I've just built a new Citrix infrastructure (a XenApp 7.6 PoC, to be precise, running on Windows 2008 R2). I've created my machine catalog and my delivery groups, and integrated them with my StoreFront server (anyone who follows me on Twitter will know how much I hate StoreFront in comparison to Web Interface, so I won't start ranting here).

I've published out an application for testing (in this case, Internet Explorer 9), and logged onto the StoreFront for Web. I can see my published application no problem when I log on to StoreFront


but when I go to launch it, this is what I see instead of my application


That isn't a published application - that's a full-fat published desktop. Very odd!

Resolution

Fortunately, I've come across this behaviour quite a few times before, so it won't have me as stumped as the first time I saw it.

The answer is to do with the user properties in Active Directory. If a Windows 2003 FFL user is edited from a Windows 2008 or higher console, the userParameters attribute becomes corrupted. This piece of neat VBscript (apologies for no credit given - I can't recall where I picked it up from, please let me know if it's yours!) should do the trick as far as resolving it goes, naturally switching the CN (canonical name) for the CN of your affected user.

If you don't know where to find the CN, first open the Active Directory Users and Computers snap-in (if you're not a dinosaur like me, and use modern stuff like the Active Directory Administrative Center, sorry, you will have to find the way yourself) and enable the Advanced Features as below


Next, find your user having the issue, open up the Properties dialog, and switch to the Object tab


The CN is shown in the box in the centre.

The VBScript we need to use is shown below. You will need to modify it for the problem user using the CN.

Const ADS_PROPERTY_CLEAR = 1 
Set objUser = GetObject _
("LDAP://cn=MyUser,ou=MyOU,dc=MyDomain,dc=com") 
objUser.PutEx ADS_PROPERTY_CLEAR, "userParameters", 0
objUser.SetInfo

So if we modified the script for the user details shown above, the script would look like this

Const ADS_PROPERTY_CLEAR = 1 
Set objUser = GetObject _
("LDAP://cn=James Rankin,ou=Standard Users,ou=User accounts,dc=JRR,dc=test,dc=local") 
objUser.PutEx ADS_PROPERTY_CLEAR, "userParameters", 0
objUser.SetInfo

Save your modified file with a .vbs extension, and then run it from the command line using cscript (I've done it as an admin from the domain controller, but not sure whether that particularly matters


And let's now log back on to the StoreFront web page and give my published application another go....


...as we can see it is all good now.

One quick note - you may also see this behaviour if you configure the type of delivery group for the application to be "Desktops and applications" as shown below and you've just got one application configured. The choice of delivery types is discussed nicely in this article by Bas van Kaam http://www.basvankaam.com/2014/06/26/configuring-citrix-xendesktop-7-x-desktop-publishing-and-limited-visibility/, rather than me go into it here.


There is one more possible solution I've come across, if those mentioned above don't work for you:-


Summary

So, just a quick article on a Citrix issue today, so that I don't have to go digging next time I see this issue crop up. Hopefully as the world moves away from Windows Server 2003 it should become more and more scarce, but given that I had a query about a Windows 2000 desktop issue only yesterday, it may be relevant for a few years yet!
↧

QuickPost - how to check Internet Explorer version in AppSense DesktopNow (or PowerShell)

January 16, 2015, 6:41 am
$
0
0
I'm trying to do more of these "QuickPost" articles as I work on some big ones. This particular post was going to be part of the ongoing investigation I've been doing into the roaming behaviour of Internet Explorer's Cookies and History, but seeing as though that is dragging into a third week (and I always make a point of taking Saturdays off!), I've decided to quickly blog this part up to keep articles ticking over.

One thing I've found in my breakdown of all things Internet Explorer, from versions 8 to 11, is that Microsoft love to change things between versions. A lot. I'm not going to get into how much of a pain this is for people like us who have to roam settings between vast arrays of different devices and form factors (but it is!!!) What I found useful, though, during this time of pain and testing, was the ability to tell what version of Internet Explorer was installed on a particular machine, so I could then tailor the Actions in Environment Manager to the installed version. Obviously, if you don't use DesktopNow, this method of determining the version may prove useful too.
 
This doesn't account for machines that may have different browser versions layered or streamed into the base operating system - this deals specifically with the version of Internet Explorer that the OS "believes" is installed because it is what is in the base image.

To determine the Internet Explorer version, we are just going to use a Custom PowerShell Action to set a Machine environment variable. Nice and simple. We will check for the version in the Startup trigger, so the variable will be set each time the system boots.

The odd bit about this is that the Registry value that holds the Internet Explorer version changes from version 9 to version 10. In IE9 or lower, the value is called Version. In IE10 or higher, it's called SvcVersion. Weird.

Easiest way around this is an If Else Group. If the svcVersion Registry value exists, pull the version from it. If it doesn't exist, pull it from Version instead. If you downgrade your IE, this may not work, but for most situations it should be fine.

The PowerShell we will use is this (lines will probably have wrapped). Edit the value of Version/svcVersion as necessary (there's a config for download at the end if you prefer to use that)

$ieVersion = New-Object -TypeName System.Version -ArgumentList (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Internet Explorer').svcVersion/Version
$ieVersion = New-Object -TypeName System.Version -ArgumentList ($ieVersion.Major, $ieVersion.Minor, $ieVersion.Build, $ieVersion.Revision)
[Environment]::SetEnvironmentVariable("IEVersion", $ieVersion.Major, "Machine")


Don't forget to set it to Run As SYSTEM - you need admin rights to create a Machine environment variable


We will add this to the Computer | Startup trigger


So when we restart the endpoint, we should now see a numeric value set for our environment variable


Incidentally, if you're wondering where in the Registry Machine environment variables live, it is in HKLM\SYSTEM\CurrentControlSet\Control\Session Manager\Environment


And that's all there is to it - you can now query the base OS installed Internet Explorer version just by matching or querying the environment variable, as necessary (or use it in a script or other software if you're not a DesktopNow user)


A copy of the configuration to do this can be downloaded here, just to keep you right. Now back to IE :-(
↧
↧

The AppSense Bigot turns three - is WEM the future of UEM?

February 7, 2015, 4:25 am
$
0
0
It's three short years today since I started up this blog...so I thought today we might have a bit less technical discussion, and more of the sort of thing I normally do in my capacity over at The Virtualization Practice - which is occasionally speculate idly on the future of our industry.

Interesting to note that when VMware acquired UEM solution vendor Immidio last week, one of the points that ex-AppSense big cheese Harry Labana - who was heavily involved in VMware's acquisition of CloudVolumes - made was the idea of Workspace Environment Management. Whilst on the surface this appears to be another attempt to foist a new three-letter-acronym on us, or initiate a new buzzword, it does seem to have some valid points around it.


So is Workspace Environment Management the designated successor to User Environment Management? The original UEM definition that I go by (courtesy of those Smackdown enthusiasts over at PQR) would appear to suggest that this is not so, and that WEM is nothing but another buzzword...

User Environment Management delivers and maintains the User Workspace in a clear, visible, predictable and profound way independent of the Application and Desktop Delivery concept and understands the context of the user Access Scenario. Having a clear view of the access scenarios, also known as personas, is essential and crucial for a complete Application and Desktop Delivery solution.

So - nothing to see here, move on?

One thing that has been common to UEM (so far!) is that it has always dealt specifically with Windows-based applications and desktops. This is to be expected - the great mass of applications and workspaces in the world are, at the moment, predominantly Windows-based. But do VMware smell a sea-change coming? One of the key words they use is "flexibility", and they put the focus firmly on delivery of the user virtualization piece across "physical, virtual and cloud-based desktops". This of course ties in nicely with the whole end-to-end idea of VMware's cloud services offering.

So, are VMware alluding to Workspace Environment Management as the ability to manage all of your workspaces and applications, not just the Windows-based ones? Or is there another meaning behind the new WEM buzzphrase - that you can include "application delivery" and monitoring as part of the UEM offering, therefore giving you the full WEM experience, which VMware can do by tying Immidio's Flex+ offering up with AppVolumes (formerly CloudVolumes) or ThinApp?

With regards to managing non-Windows workspaces, the only way to reliably achieve this currently is if you're using something like XenApp or RDS to host Windows applications, and then deliver the applications to your non-Windows client (via the Citrix Receiver, for instance) with the UEM already baked-in. If you're using a native application, then there won't be any UEM there. This is a problem that is probably going to become more prevalent - think, for example, of DropBox. It can run on Windows, iOS, OSX, Linux, Android, even Blackberry, Kindle and Windows Phone. Being able to persist contextually-aware settings between these platforms would be awesome! If this is what VMware are driving at with WEM - sign me up!

If it's the concept that the delivery of applications and monitoring is integrated with the user environment management - effectively merging your app virtualization together with the user virtualization - then this is less of a winner. Whilst still good - this reduces your reliance on third-party solutions - it's only really compelling if you've already got a solid investment in VMware technology (although to be fair, a lot of people have). There are many other app virtualization and layering solutions out there, some of which are better than others in terms of features or compatibility. Monitoring-wise, again, everyone tends to already have a solution in place - monitoring is by no means restricted to the end-user arena - but if it brings something extra to the table, such as monitoring the VDI session in greater detail, then maybe it could be of interest.

So what could the likes of AppSense do in response to VMware's play towards this new, WEM solution? AppSense have done a good job of "back to basics" over the last year, given that the DesktopNow product, their most popular one, was showing signs of being slightly neglected in favour of their mobile push. I'm currently beta testing the latest version - and they've gone a long way to making the difficult things, like profile migrations, vastly simpler. The focus back on existing customers has been good - but does VMware's entry into this market signify that they will have to shift back to forward development once more?

In my own personal opinion, VMware's acquisition of Immidio had to happen. Their existing profile management piece, View Persona Management, was simply too limited to be even considered as a UEM solution, paling badly even when put up against "lite" contenders such as Citrix Profile Management or Microsoft's UE-V. The acquisition of Immidio gives them a proven solution, lightweight and easily-deployed, which offers much more to the end-user than Persona Management ever did. They've got the pieces of the jigsaw now to produce something compelling on the UEM end - and the budget, and the staff (such as Shawn Bass) to make it so. How should the traditional UEM vendors respond?

Some of you may remember a rumour about something coming out of AppSense (circa 2012) called Project Acorn, which so far I've heard no further mention of. This was intended to be UEM for OSX, allowing Environment Manager to extend onto Apple desktops. If VMware are starting to make noises about a possible flexible, platform-agnostic solution to application and user virtualization, then AppSense could do no worse than reinvoke Project Acorn and extend their solution onto the Apple workspaces in the enterprise. Microsoft are opening up and pushing their solutions more broadly into other non-Windows corners of the market, and becoming less disliked by doing so - maybe it's time for other companies to follow suit? Imagine AppSense EM and AM running natively on company-owned tablets, mobiles, Linux desktops, all the devices out there? It would be a cool management solution. In fact, given that they have experience of multi-homing their solutions with DataNow and MobileNow (although MobileNow seems to be disappearing), I'm hoping this won't prove to be too much of a jump. Please, make it so!

All in all, kudos to VMware for having the foresight to try and shake up the UEM market a bit. It will be interesting to see exactly what their vision for WEM is, and how they go about putting it together. I'd love to see a single solution that can deliver client-side application and user settings across multiple platforms, and I think AppSense are particularly well positioned to make a fist of competing on this level. Of course, when Microsoft get their way and every application in the world runs as SaaS from an Azure datacenter, we will be able to do away with the WEM/UEM solution entirely and keep all our settings on the server end. As long as your internet connection never, ever goes down :-)

**** Thanks to everyone for listening to my ramblings for the last three years! If you have a subject you'd like me to cover on this blog, please feel free to post it in the comments section or drop me an email at kz20fl [at] googlemail [dot] com ***

↧

IE10 and IE11 Cookies and History persistence - a deep dive, part #1

February 11, 2015, 7:35 am
$
0
0
I've spent weeks looking at the issue of Cookies and History persistence now, since I was alerted to the possible issues in the first place. It's been a frustrating voyage of discovery, punctuated with epiphanies, server rebuilds and quite a few journeys straight back to the drawing board. So, I thought it would be prudent to share my findings with all and sundry, just to give you a heads-up on what potentially awaits!

This article is going to be divided into three parts. Part 1 will cover the background and my initial tests using traditional methods vs. AppSense DesktopNow methods. Part 2 will spread out further and perform testing on some of the "lite" UEM technologies to see how they measure up to this infuriating task (UPM and UE-V). Part 3 will extend the tests onto some more UEM tech (actual vendors to be confirmed).

First of all, let's get a disclaimer in. This is only based on testing in my lab on a limited set of parameters, so I'm not expecting these to be absolutely indicative of what you may observe in your own environments. In fact, the reports I am getting from others in the field suggest that you may see markedly different behaviour dependent on the nature of your web applications and users. However, I am hoping that this can provide some pointers on what to expect, in order to save others from the rollercoaster that I seem to have experienced!

I've provided configurations for the various methods I used for testing, but please edit these carefully - they are specifically designed for my lab, so you will need to pay attention when setting them up for your own environments. I'm not going to be held responsible for any production-level disasters you may cause through lack of due diligence!

Background

If you want to read in great detail what Microsoft have changed when moving from IE9 to IE10+, this should provide you with exactly what you require.

What's annoying is that Microsoft appear to have made these changes without any thought to those of us who have roaming user environments. XenApp and Terminal Server technologies have been around (in technology terms) for an absolute age. Can Microsoft really be this far behind the curve in dealing with users who want persistent settings across multiple endpoints?

IE10 makes things easy? Pull the other one, Microsoft

Folder Redirection has long been Microsoft's preferred way of dealing with issues like this - but the fact that you can't actually redirect Cookies and History using Microsoft's GPO method should be a bit of a warning. Naturally, you can do it via Group Policy Preferences just by setting the right value in HKCU\Software\Microsoft\Windows\Explorer\User Shell Folders, but this is apparently not recommended. Even if you were using a roaming profile, History would still be out of the equation (as we will soon see), because it lives in %LOCALAPPDATA%. I've seen forum posts suggesting getting around this by redirecting %LOCALAPPDATA% using symbolic links - and that just sounds like a world of application-level hurt.

I'd be interested to find out Microsoft's official position on redirecting Cookies and History - although their silence in the face of my continued complaints about this issue has been deafening (more on this further on). It seems ludicrous that in a modern age we should still be stuck with the possibility that a user can't roam some basic browser settings from device to device - and even more ludicrous that the so-called "improvements" to Cookies and History have killed this functionality where previously it was possible to get it to work (somewhat). The one article I did find offers a fantastic quote which shows how far in the dark ages Microsoft is capable of being - imagine this in a XenApp environment with siloed applications... "Restrict roaming user profiles so they work on only one computer at a time. Using a single roaming profile on multiple computers isn’t supported (via console or Remote Desktop) and can cause unpredictable results, including cookie loss."

It's also really annoying that even if you can get Cookies and History to roam, on Windows 8.x and Server 2012 this only applies to the desktop version of Internet Explorer. If you're using any of the newer Windows' versions fancy Modern bits, then you're screwed - Cookies set by the Immersive version of IE or by Windows Store apps can not be managed in a roaming profile.

And a word on redirection in general. For things like Documents, Favorites, Downloads, etc., I'm still a big fan of Folder Redirection, but for anything that involves a lot of small files or files that are closely tied to the operating system - such as History and Cookies - I'm starting to feel it should be handled differently. Certainly, I have observed my best results when I've taken Folder Redirection out of the equation. It always seems to be working, but I've never done such a protracted amount of testing on a single process before. With redirected Cookies and History, you seem to observe a lot of odd and inconsistent behaviour. Sometimes cookie warnings reappear. Occasionally cookies don't roam until your second or third logon. Some websites don't add themselves to History. You see other strange folders appearing in the root of your redirection. Lots of little niggly things happen that are difficult to reproduce, and these sorts of issues are the bane of users and support staff alike. In fact, it's possible that Favorites redirection isn't such a great idea either - see this article for some discussion of it.

Even in an environment where the "local" drives and "network" drives sit on the same storage, there seem to be a plethora of niggly, annoying issues that can appear - not a flat out failure, just a depreciation in the solution's reliability. If you want to dig further into the impact of redirection of certain folders (such as %APPDATA%, a really contentious issue), let me point you in the direction of an excellent series of articles by Helge Klein, Aaron Parker and Shawn Bass.

Environment

In my test environment, I've prepared three distinct platforms. We have a Windows Server 2008 R2 RDS Server, a Windows 2012 R2 RDS Server, and a Windows 8.1 client. I did also want to test this on Windows 7, but Microsoft appear to have hidden the trial versions of Windows 7 so successfully, they've made testing on it no longer possible.

Platform 1

Windows Server 2008 R2 SP1 RDS, fully patched (including latest IE cumulative updates)
Citrix XenApp 7.6

Platform 2

Windows Server 2012 R2 RDS, fully patched (including latest IE cumulative updates)
RemoteApp

Platform 3

Windows 8.1 client, fully patched (including latest IE cumulative updates)

There are no other applications installed, and no antivirus. Active GPOs are Disable IE Enhanced Protected Mode, Delete cached copies of roaming profiles, Allow creation of symbolic links and Disable UAC.

When using persistence methods that leverage AppSense DesktopNow, I actually used the beta of EM 8 FR 6 (a bit silly, I know, but I was in the middle of beta testing). I'm hoping there isn't that much difference in the operation of Personalization Server and Policy from EM 8 FR 5!

On Server 2008 R2 we will test IE8, IE9, IE10 and IE11, and on the other platforms IE11 only. Each instance will have the latest cumulative IE updates applied for the required version.

Persistence methods

We've defined quite a few persistence methods. I'd expect the "normal" method that people are currently using in AppSense DesktopNow to be Method 7 (AppSense Personalization Server with Redirection). We've covered quite a few to try and get an idea of what works, and what doesn't.

Where "Redirection" is included this means we will be redirecting the Cookies and History folder to network locations (you have to do this through Environment Manager - it isn't supported by GPO, although you could simply use Group Policy Preferences to set the required Registry value). You may notice that the AppSense EM Folder Redirection Action doesn't work for History if you're aiming at a network drive - you have to set the Registry value through a Registry Action instead. This is actually due to a limitation of the Microsoft Folder Redirection API, which can only redirect History to a local folder, so it's always been the case that you would need to use a Registry Action to push this to a UNC path (thanks to Richard Thompson for the education).


Method 1 - Local profile

Quite simple, we are using a local profile that persists on the endpoint.

Method 2 - Roaming profile

Again, very simple, a standard Microsoft roaming profile.

Method 3 - Roaming profile with redirection

This method uses a standard Microsoft roaming profile with the Cookies and History folders redirected to the network.

Method 4 - Mandatory profile with redirection

This method uses a standard Microsoft mandatory profile with the Cookies and History folders redirected to the network.

Method 5 - AppSense full Personalization Server (with mandatory profile)

This method puts all of the data into Personalization Server, including Cookies and History. The exact settings are covered in the Details section below. When using this method with IE10 or higher, the Windows Personalization Group for IE10+ Cookies and History must also be added to the Personalization Group.

Method 6 - AppSense file and Registry hiving (with mandatory profile)

This method eschews Personalization Server and puts all Internet Explorer settings into Policy Configuration which are loaded at logon and saved at logoff. The exact settings are in the Details section.

Method 7 - AppSense Personalization Server with redirection (with mandatory profile)

This is what most AppSense admins would probably consider the "traditional" method of saving these settings - Personalization Server for the IE settings, with Cookies and History redirected to network locations. We have edited it slightly though - see the Details section.

Method 8 + 9 - Citrix User Profile Manager and Microsoft UE-V

The intention was to test two of the lighter UEM versions as part of this, but the first seven methods took so long I've had to move these across to part #2 of the article.

Details

We've made a few changes from the defaults in our persistence methods - these changes (and downloadable configs) are detailed herein.

Globally, we have set a Computer Startup Action to list the Internet Explorer version as a variable (see this post for more details). This is required because versions 10 and 11 introduce some aberrant behaviour which needs to be dealt with at process launch. Dependent on how you deploy your new versions, you may or may not need something similar. The required Actions are contained in all of the configurations that are available for download here (see later).

Method 1 + 2 - local/roaming profile

No special configuration is required here, merely the presence of the profiles.

Method 3 + 4 - Roaming/mandatory profile with redirection

These methods need Folder Redirection configuring for Cookies and History - to do this through EM, use a configuration similar to this one (change to match your infrastructure, obviously).

Method 5 - AppSense full Personalization Server (with mandatory profile)

In order to set up this method, you need to make a few changes to the Personalization Server settings (well, quite a bit, actually). First, we need to take {CSIDL_COOKIES} and {CSIDL_HISTORY} out of the top-level application exclusions so that the Cookies and History data will actually be saved into Personalization Server.

Remove {CSIDL_COOKIES} and {CSIDL_HISTORY} from the global exclusions
Next, we need to configure the includes and excludes for our Internet Explorer Application Group. They are slightly different from the defaults.

Folder Includes and Excludes for the IE Application Group
Registry Includes and Excludes for the IE Application Group
The most notable change is the addition of  the key HKCU\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache to the Registry Includes. This seems to deal specifically with History persistence.

Now you'll need to link the IE10+ Cookies and History Windows Personalization Group to the specified Personalization Group. You will need to edit the settings in this group (may be an idea to clone it first) and add this Registry key into it also


HKEY_CURRENT_USER\Software\Microsoft\Windows\CurrentVersion\Internet Settings\5.0\Cache\Extensible Cache

(Yes, that's the same one as we've already added into the Application Group, but it seems to be necessary to duplicate them!)

Also, if you're pre-EM 8 FR 5, remove rundll32.exe from the Default Blacklist.

Finally, you will need to configure the settings to reset file attributes on the History folder if IE10 or IE11 is detected - download the configuration with these Actions in here (change to match your infrastructure).

Method 6 - AppSense file and Registry hiving (with mandatory profile)

This method needs all of the IE settings removing from Personalization Server (including the Windows Personalization Group, if we are on version 10 or higher). You should then apply the following configuration (very carefully change this to match your infrastructure), which should save all settings for Internet Explorer onto a network location at logoff and reimport them at logon.

It's maybe worth noting at this point that using this method for IE settings may have much more mileage in it in general. Think of how many (non-browser) applications actually use IE settings these days - for instance, where do applications get their proxy server settings from? As IE is tied so closely to the Windows operating system, it may be worth dealing with it as an OS-level setting, rather than an application in itself.

Method 7 - Personalization Server + redirection (with mandatory profile)

This is probably the method you may already be using, but we have made a few adjustments. Firstly, make sure that {CSIDL_COOKIES} and {CSIDL_HISTORY} are in the global exclusions list, rather than removed as in Method 5 above. Then, make the changes to the Internet Explorer Application Group settings in the same way (they are reproduced below again for posterity). As we're using redirection, the Windows Personalization Group for IE10+ Cookies and History should not be linked to the Personalization Group.



An example configuration is supplied here, which also includes the file attribute reset routine for the History folder (change to match your infrastructure).

Testing process

We also need to clearly define our testing parameters. In the interests of trying to keep it fairly straightforward and not overly time-consuming, we set up a few simple tests for persistence of Cookies, and History. One of the more pertinent tests was the one which checks whether History still persists when the system clock was moved forward by 48 hours. In our testing, there were a lot of times History would persist, but only for a period of one day (I actually observed this on a client site over three years ago).

It's worth clarifying at this point what we actually mean by History (I've seen many people confuse this in the past). We all know what Cookies are (hopefully!) - let's make sure we're in agreement about History too. Some people mistake History for the record of items typed in the IE Address Bar - but just so you know, I (and Microsoft) refer to that as "TypedURL History". "History" is what you get when you click the "star" button in IE (see below), or press Ctrl-H in IE8.


Test 1

Browse to www.google.co.uk. Respond to the cookie warning. Log the session out, log back in, verify that the cookie warning no longer appears.


Test 2

Log in to an account at mail.google.com. Close the session. Log back in, verify that the Google Mail account logs in automatically using the cookie.


Test 3

Browse to www.bbc.co.uk/news. Respond to the cookie warning. Log the session out, log back in, verify that the cookie warning no longer appears.


Test 4

Browse to theregister.co.uk. Respond to the cookie warning. Log the session out, log back in, verify that the cookie warning no longer appears.


Test 5

Open up the History folder. Verify that the websites visited so far all appear in History. Log the session out, log back in, verify that the History is still present.


Test 6

Put the system clock forward 48 hours. Log in and verify that the History and Cookies are still persisting correctly (pay particular attention to History).


These tests will be repeated, as we specified previously, for IE8, IE9, IE10 and IE11 on Windows Server 2008 R2, and on IE11 only for Windows 2012 R2 and Windows 8.1.

Results

So, let's see just how well each of these persistence methods fared!

Internet Explorer 8 on Windows Server 2008 R2


Test 1Test 2Test 3Test 4Test 5 Test 6
Local profilePassPassPassPassPassPass
Roaming profilePassPassPassPassFailFail
Roaming profile with redirectionPassPassPassPassPassPass
Mandatory profile with redirectionPassPassPassPassPassPass
AppSense (full PS)PassPassPassPassPassPass
AppSense (file and Registry hiving)PassPassPassPassPassPass
AppSense (PS with redirection)PassPassPassPassPassPass

Nothing really to note about these findings, except that IE8 seems quite robust. As History is stored by default in %LOCALAPPDATA%, the failure on the last two tests of the roaming profile is expected.

It is interesting to note that the Google cookie warning (Test 1) didn't actually appear at all on IE8, not even the first time. Also, to get rid of the Google "Update your search engine" warning, you actually need to add google.com and google.co.uk to Compatibility View. These anomalies aside, though, everything behaved entirely as we thought it would.

Internet Explorer 9 on Windows Server 2008 R2



Test 1Test 2Test 3Test 4Test 5 Test 6
Local profilePassPassPassPassPassPass
Roaming profilePassPassPassPassFailFail
Roaming profile with redirectionFailPassPassPassPassPass
Mandatory profile with redirectionFailPassPassPassPassFail
AppSense (full PS)PassPassPassPassPassPass
AppSense (file and Registry hiving)FailPassPassPassPassPass
AppSense (PS with redirection)FailPassPassPassPassPass

It's here that my previous observations about redirection start to show up, regarding the occasional oddness displayed when using it. The fact that a mandatory profile failed Test 6 whilst a roaming profile passed is rather strange, as the folder should be redirected onto the network for both methods.

Test 1 (Google cookie warning) failed on quite a few of the persistence methods. However (as they constantly reminded me!) IE9 is no longer a browser supported by Google, so it is possible this may have been the reason for this. Also, the Compatibility View fix mentioned earlier, to get around the Google update warning, still stands.

Migration of settings from IE8 to IE9 appears flawless. The existing settings appeared without any fuss, so clearly both browser versions are using the same processes under the hood.

So, a couple of anomalous observations, but otherwise IE9 seems pretty good for persistence of user Cookies and History data.

Internet Explorer 10 on Windows Server 2008 R2


Shudder...

Test 1Test 2Test 3Test 4Test 5 Test 6
Local profilePassPassPassPassPassPass
Roaming profileFailPassPassPassFailFail
Roaming profile with redirectionFailFailFailFailFailFail
Mandatory profile with redirectionFailFailFailFailFailFail
AppSense (full PS)PassPassPassPassPassPass
AppSense (file and Registry hiving)PassPassPassPassPassPass
AppSense (PS with redirection)FailFailFailFailFailFail

So, we can straight away see that involving redirection in this mix leads to a whole bunch of fails. All of the persistence methods that utilize redirection capitulated utterly.

There is also an awful problem of "inaccessible History" that showed up quite a lot in Test 5. This manifests as the History folder being completely blank (see below). The History data is there (you can see it in the Address Bar on occasion), it is simply missing from the History tab. To get around it for Methods 5 and 6, we implemented a file attribute reset Action at IE Process Start via AppSense EM (included in the configurations). This didn't work for Method 7 - resetting the attributes only seems to work when the files are not redirected.

The "inaccessible History" issue in all its glory


All in all, Internet Explorer 10 demonstrates that redirection of Cookies and History, which seemed to work in IE8 and IE9, is now pretty heavily broken. Glorious.

Internet Explorer 11 on Windows Server 2008 R2


Test 1Test 2Test 3Test 4Test 5 Test 6
Local profilePassPassPassPassPassPass
Roaming profileFailPassPassPassFailFail
Roaming profile with redirectionFailFailFailFailFailFail
Mandatory profile with redirectionFailFailFailFailFailFail
AppSense (full PS)PassPassPassPassPassPass
AppSense (file and Registry hiving)PassPassPassPassPassPass
AppSense (PS with redirection)FailFailFailFailFailFail

At last, some consistency! That's consistency in the sense that IE11 on Server 2008 R2 exhibits the exact same results and problems (inaccessible History) as IE10 did.

Internet Explorer 11 on Windows Server 2012 R2


Test 1Test 2Test 3Test 4Test 5 Test 6
Local profilePassPassPassPassPassPass
Roaming profileFailPassPassPassFailFail
Roaming profile with redirectionFailPassPassPassFailFail
Mandatory profile with redirectionFailPassPassPassFailFail
AppSense (full PS)PassPassPassPassPassPass
AppSense (file and Registry hiving)PassPassPassPassPassPass
AppSense (PS with redirection)FailFailFailFailFailFail

Windows Server 2012 with IE11 differs from Server 2008 R2 in one way - Cookies redirection doesn't fail when using a roaming profile. But, strangely, Method 7 is still a complete failure. History is still another matter though - only Methods 5 and 6 managing to cut it, and that's with the file attributes jiggery-pokery included.

Internet Explorer 11 on Windows 8.1


Test 1Test 2Test 3Test 4Test 5 Test 6
Local profilePassPassPassPassPassPass
Roaming profileFailPassPassPassFailFail
Roaming profile with redirectionFailPassPassPassFailFail
Mandatory profile with redirectionFailPassPassPassFailFail
AppSense (full PS)PassPassPassPassPassPass
AppSense (file and Registry hiving)PassPassPassPassPassPass
AppSense (PS with redirection)FailFailFailFailFailFail

Unsurprisingly, IE11 on Windows 8.1 displayed the exact same behaviour as Windows Server 2012 R2. Nothing new here.

Findings

Well, let's review what we've learned here.

Folder Redirection seems to work quite acceptably when using IE8 and IE9. But go to IE10 or higher, and Folder Redirection breaks dramatically. Reasons for this are possibly the WinInet Scheduled Task, dllhost.exe, and a whole host of other hooks that show up in Process Monitor. I documented some ways to get around this previously, but putting together a load of programmatical fudges to allow Folder Redirection to function as it did previously just doesn't feel right.

There were two persistence methods that did work consistently in my testing - the "AppSense Full Personalization Server" method and "AppSense File and Registry Hiving". We did have to do some trickery to get these to work - most notably the "reset file attributes" trick at IE Process Start - but once this was in place they both worked consistently well. Is this the way forward?


The "reset file attributes" trick that gets Method 5 and 6 to work with IE10+


Despite the fact that it worked consistently in these tests, I do have reservations about Method 5 (full Personalization Server). Putting Cookies and History into the Personalization Server database will involve dealing with lots of small files that are being written quite aggressively, and there will more than likely be a big performance hit involved over time. Add to this the fact that both the IE Application Group and the IE10+ Cookies Windows Personalization Group will both be trying to capture these sets of data (on IE10 and higher), and you've got a method that might work, but also may cause you issues further down the line.

That leaves us with Method 6 (File and Registry Hiving). This is somewhat convoluted to set up and maintain (although the supplied configuration may give you a head start), but it does seem to work reliably. Given the plethora of applications that leverage Internet Explorer settings these days, it may well be a very good idea to use this approach. There's also the fact that doing this in Policy rather than Personalization allows you to use the multi-threaded engine instead of the single-threaded one. There are drawbacks, though. The data can get big, particularly when you move to IE10+ - I've seen the database heading up towards 100MB in some cases. Multiply that by thousands of users, and you're talking a big hit, storage-wise. You also have to copy this data in at every logon, which may or may not be an issue. You also lose the rollback feature of Personalization Server - but you could replace it with something like Volume Shadow Copies. Actually, there are ways to take data like this and capture it into Personalization Server at logoff, allowing you to use the rollback facilities - but that's something we will cover in a future post, as this one is long enough already!

Some of you may be wondering if using Method 7 (Personalization Server + Redirection) would work for IE10+ if combined with the supplied Windows Personalization Group for IE10+ Cookies and History? It well might (I think this was the conclusion I drew in my previous article on Cookies), but the fact that you are both redirecting the folders and capturing the data into Personalization Server makes it a solution that is effectively working at cross-purposes, which is why I didn't consider it for this testing. It may also cause issues further down the line.

I suppose you could combine Folder Redirection with some scripted goodness to reset the attributes on the History folder to get this working on 2012 R2 or Windows 8.1, but that doesn't help you with any Server 2008 R2 instances (or Windows 7, possibly) that you may have. I'm still annoyed I couldn't do the testing on Windows 7, but I'm willing to lay money that it shows the same results as Server 2008 R2. @byteben may be able to confirm or deny this at some point - I know he's had a lot of trouble with Windows 7.

I've been through a lot of pain with this. I've tried crazy things like inserting symbolic links, redirecting %LOCALAPPDATA%, even redirecting the Internet Explorer Extensible Cache. But what I really think (and I might be about to start ranting here), is that Microsoft should fix the f*cking thing (apologies for swearing, but I'm annoyed).

Seriously, why come up with a method for storing IE Cookies and History that doesn't play well in an environment where users roam between devices and sessions? I know they dropped us a big hint that they didn't care about roaming users when Cookies and History were not able to be redirected natively through GPOs any more, but come on, Microsoft, please get a grip. Modern computing environments are agile, comprising different devices, operating systems, and application delivery platforms. But my users can't roam natively between sessions on, say, two XenApp servers and get a consistent experience in terms of the browser data? It's just insane. And what makes it worse is that after all my complaining on Twitter, I was contacted by a Microsoft employee who offered to put me in touch with someone who could help. I was very excited by the prospect of finally maybe finding a way around this that didn't involve using AppSense DesktopNow in the way we have. But despite chasing them on a number of occasions, the last I heard was "the person who can help you is at a conference". That was it - and I've heard nothing since. For a company the size of Microsoft, that's just ridiculous. And compared to people I've had dealings with at Citrix, VMware and AppSense, it's the most unhelpful I've ever known a tech company to be. Basically I've just been ignored. Microsoft, your attitude sucks. If this was a Citrix issue I bet I could've gotten help from the CTP community in a flash, a community that would raise the issue with the vendor if necessary. Microsoft themselves have been absolutely f*cking useless. Period.

Summary

Want your Cookies and History roaming on IE10+? At time of writing, your options seem to be quite limited. Either use AppSense DesktopNow in one of the ways we've described herein, or change your browser. Or maybe go back to IE9. Or you could even use a local profile, but you'll be limited in the scope of your roaming, limited as in restricted to one machine, which by definition isn't roaming at all. That's about it.

That doesn't cover the other UEM vendors out there, though. In part #2 of this article, I will run the same tests past UE-V, Citrix UPM, and any other UEM products I can get my hands on.

As I said earlier, I doubt that my lab testing will reflect absolutely what you may observe in your own environments. However, I sincerely hope that the write-up here may allow some of you out there about to cross this bridge to do so with a deal more knowledge (and forewarning!) than you had previously!

Update - part #2 of this article is now available
↧
Search

Windows 10 part #3 - roaming the Windows 10 Start tile settings

September 10, 2015, 2:42 pm
$
0
0
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!

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!

P.S. Thanks to those who sent me wedding congratulations on Twitter or email!
↧

QuickPost: Windows 10 RSAT installed but no snap-ins or shortcuts available

September 17, 2015, 8:02 am
$
0
0
In my unfortunate adventure delving deeply into the unholy under-the-hood mess that is Windows 10, I've been wanting to load up the Remote Server Administration Tools (RSAT) so that I can take advantage of the latest Windows 10 ADMX files. For some reason, if I install the Windows 10 ADMX packages on my 2012 R2 DCs, I don't see any Windows 10 settings in there. In these situations (I can still remember running RSAT on Windows 7 clients to get the new-at-the-time Windows 7 settings for my old 2003 domain) it's normal to go to a client of the required OS and install the RSAT package on there. Then you can connect up to a DC and manage your GPOs (and everything else you want to manage as well) from the client. Simples.

Or so I thought.

I started by spinning up a Windows 10 Enterprise LTSB virtual machine, and then simply browsing to the required URL to download the RSAT package for Windows 10 - https://www.microsoft.com/en-hk/download/details.aspx?id=45520



Once at the download page, we simply select the x64 package which is appropriate for our system, and open it up to run


After allowing pop-ups, we get the required update package downloaded as requested


Once we click Yes, we get the standard license agreement


And then off it goes to install. However, to me, the installation seemed very quick. In fact too quick.


This feeling is tempered when I open up the Run command and type in "gpmc.msc" (which is the Group Policy Management Console, exactly what I'm looking to get from this)


Say what? Just to make sure I'm not going completely insane, I load up mmc.exe from the Run command and look to see which snap-ins I can load...


...and this is clearly wrong. There should be considerably more snap-ins available to load in there - everything except DHCP Management and NPS Management, as far as I can tell from the RSAT documentation. This doesn't look good. What's gone wrong?

Next stop is obviously the event logs....but these are also utterly inconclusive. They simply report that the update started being installed and finished successfully - but the timestamps indicate it was almost instantaneous, which leads me to believe it didn't install successfully at all.


What next then? I tried a restart (yes, the systems administrator in me is still there), but that didn't improve anything. So off to Google it was.

So deep down on some message boards, I found a thread from earlier this year mentioning that the first Windows 10 RSAT release (for the Insiders) was available in English US areas only. Could that be something worth investigating?

Off I went then into Windows 10's schizophrenic settings, going to Start | Settings | Time & language | Region and Language. Why everything just isn't in Control Panel I may never know.


Select United States in the top bar and then click on Add a language to be taken to this screen


Scroll merrily along until you find English, click on it, then find and click on English (United States)

You will return to the previous screen, but now with English (United States) in the Languages list. Click on it and choose Set as default


Now you should see the US English has moved up the list to the top. Click on it again and select Options


You should now see an option for Download language pack, so go ahead and download and install it. If you don't have that option, there's a chance it's already installed, so you won't need to do this bit (either that, or you've disabled Windows Update!). Tip - if you want to see what language packs you have installed run lpksetup from an elevated command prompt or the Run command as an admin.


Now, once the language pack is installed correctly, let's try running the RSAT installer again. If you haven't saved it (like me!) you'll have to download it again from the Microsoft page. What happens this time?

Well, as the Aussies (allegedly) say, strike me pink. Now the installation appears to be taking the requisite amount of time (a good minute or two), and at the end, it wants to be restarted. Let's give it what it wants!


After the restart, we can try to run our Group Policy Management Console (gpmc.msc) again...


...and hey presto! We're back in business. Just for posterity, let's load up mmc.exe and see how many snap-ins we have available...


...and as we can see, loads of snap-ins!

If you now switch your default language back to UK English, you should find that the Remote Server Admin Tools still work. However, if you uninstall the US English Language Pack for any reason or remove it as an installed language, you will find that the RSAT will cease functioning again.

I'm assuming this is a bit of weirdness Microsoft will eventually correct, but for the moment, if you want Windows 10 RSAT running, then you will have to make sure the US English stuff is installed.

And finally, on the Windows 10 subject, the many things I've been discovering about this new (and annoying) operating system will form the basis of a presentation I'm giving at the Citrix User Group in London on 30 September (provisional presentation title - Profile management challenges in Windows 10). Feel free to pop along and heckle me if you're in the area - post-group beers are always a good time!
↧
↧

Deploying per-user file type associations (FTAs) on XenApp 7.6 Server 2012 R2 (slightly reloaded)

October 15, 2015, 7:23 am
$
0
0
OK. I did an article recently on how to deploy file type associations (from hereon in, referred to as FTAs) on Windows 8.x/Server 2012 R2. However, the method I finally settled on in that article turned out to be a little hit-and-miss, particularly when using security groups from AD, as borne out by the comments and emails that I received regarding it. Fortunately, myself and Mr Duncan Murdoch (who deserves a whole load of credit for doing a very comprehensive deep-dive on the inner mysteries of FTAs) put our heads together and had another stab at this, mainly looking at it from a perspective of XenApp systems (specifically, Server 2012 R2 running XenApp 7.6 Feature Pack 3).

Note - the original article has now been removed, as it was very inconsistent. Please use this one as the reference for this subject from now on!

It would probably help to do a bit of a recap of the issues and drivers behind this from the previous article, so if you've read the first one and feel like there's a bit of crossover, my apologies! However, now that the original post has been removed from the blog,it makes sense to reproduce the original background here in full.


We're all familiar with FTAs - they are the program that opens a particular file type. Files with the .docx extension open in Microsoft Word. Files with the .txt extension can open in many things - Notepad, Notepad++, even Microsoft Excel. Each user normally has a default FTA that is the program that will open it when you double-click a particular file type. If you wanted to open the file type in a different program (for instance, open a file with the .xml extension in Notepad instead of the default of IE), you can right-click on the file and choose Open With.

So why would you want to assign FTAs on a per-user basis?

Mainly, we're talking about shared systems, and for the purposes of this article we're specifically concentrating on Citrix XenApp (although this should work just as well for Server 2012 R2 Remote Desktop Session Host). When you're in a shared-session environment such as XenApp, you might want users to open files from the same server but with different applications, possibly for licensing reasons, or possibly just for user convenience and familiarity. You might want some users to open Visio files in Visio, and others in Visio Viewer. Or you might want some to open PDFs in Adobe Reader but others in the full version of Acrobat. In Windows 7/Server 2008 R2/XenApp 6.x, you could simply use Group Policy Preferences Folder Options to deploy an Open With item. Each user would get a particular application associated with a particular file extension when they logged in. Nice, easy, uncomplicated.

Enter Windows 8.x and Server 2012 R2, which is where our nice shiny new XenApp 7.6 systems sit, and Microsoft have moved the goalposts (quelle surprise). The Group Policy Preferences method I wrote about previously simply flat-out doesn't work any more. Normally, user FTA settings are written to a specific Registry area - HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts, with subkeys for each filetype (e.g. .PDF). But Microsoft appear to have changed something. Now, when you write a new filetype using the Default Programs part of Control Panel (or the Open With context menu), the Registry settings are changed in a very different way.

To show you what I mean, I've logged on to a Server 2012 XenApp 7.6 FP3 system with three different PDF readers installed locally (Adobe Reader, Foxit Reader and SumatraPDF), and I'm going to select FoxIT Reader as the applicaton to use. The way I trigger this is by right-clicking a PDF file and choosing Open With | Choose Default Program, but you can also access this through the Control Panel.


Once I select FoxIT Reader as the default program, we can see the Registry changes we'd expect - but there are some additions we haven't seen previously


Note the Hash value. Apparently, this is a hash generated from the application, the computer name and the username, and which needs to be unique in order for this key to be used. So if I export these values into the user profile and roam them to another XenApp server, the FTA will be lost. If you export, roam, save or persist this Registry key, when you move to another server system, you are prompted to choose the default program again, because the hash doesn't match. Apparently this was done to reduce tampering by malware, but it's very short-sighted because it doesn't take into account multi-session systems like XenApp and RDS.

Even more annoying, is the fact that the action of setting a default program in this way also writes a permissions change to the UserChoice key. See below


Note the Deny set for the user account that made the change (in this case I was logged on as Administrator). This means that you can't set the values in this key through a script or such like without altering the Registry permissions first. But even if you do alter the permissions, you need the Hash value to match the server system - and without knowledge of the algorithm in use, you're not going to get very far.

However, Microsoft have handily made a function available for setting the file associations. This involves setting the file association(s) for a user, and then exporting it(them) out to an XML file using the following command


Once you've exported the XML file with your configured file associations (you can edit it by hand to just get the FTAs you need), you can then deploy this at logon by using a Group Policy Object. This all sounds good so far...

...until you realize that the GPO that sets the FTA is Computer Configuration only. That's right, it writes to a Registry key in HKEY_LOCAL_MACHINE. Making it a royal pain in the proverbials for deploying to multi-session environments such as XenApp. If you don't believe me, check it out - it's to be found only in Computer Config | Policies | Admin Templates | Windows Components | File Explorer


So somehow, we've got to try and use the information in an HKLM policy value to deploy per-user settings. Not a very good starting point. In fact, even though we tested this and made it work to a certain extent in the previous article on this, it would have been very difficult to make this work on XenApp. Imagine if ten users opened sessions on the server at once, and all of them were trying to rewrite and import in the relevant policy key from a single area in HKLM? It would be chaotic.

And (possibly fortunately), the method seemed to be very inconsistent anyway. Sometimes the user would have to log in twice to get the FTA correctly applied. If you're in a XenApp environment, this would be unworkable, particularly if users were hitting any one of a pool of servers (or even desktops).

So - this is where Duncan stepped in. I've often hung around conferences with Duncan chewing the fat, and he does some very interesting work with App-V and FSLogix over on his website at www.amberreef.co.uk. He did some excellent deep-dive work on the inner mysteries of FTAs, and together we managed to come up with something that looked like it might just work...

A quick recap - we have a Server 2012 R2 instance running XenApp 7.6 Feature Pack 3. We've installed three PDF readers on here - Adobe Reader, Foxit Reader and SumatraPDF. We will set up three AD security groups to assign different FTAs dependent on the user's group memberships. We will also give our test user a mandatory profile to ensure that nothing is being saved locally to the box.

However, the first thing you will need to know to use this method is the filetype. Older heads may remember the ftype command which is probably still around in the guts of Windows today. Running this command gives you a list of all registered file types on the machine - something like this


You will need to get the relevant filetypes for the applications you are switching between. The best way to tell is pick a clean machine and install the application onto it. Most applications will register themselves as the default handler once you install them for the file extension you're dealing with (so, for instance, .pdf for PDF readers, .vsd for Visio, etc.) So once you've installed the application, jump into the Registry and check HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.extension\UserChoice (where extension is the file extension you're concerned with) and look for the Progid value. As an example, I've just installed Sumatra PDF onto my local machine (replacing Adobe Reader), and I can now see this entry in the Registry key I specified


So the filetype I am looking for is Applications\SumatraPDF.exe. Incidentally, if the program isn't as pushy as usual and you can't find the filetype here, use the Open With context menu command to set it as the default program for opening the particular extension, and it will then write here as necessary.

Following this on logically by installing the other applications, I find the latest version of Adobe Reader has a filetype of AcroExch.Document.DC, and Foxit Reader has FoxitReader.Document. Bear in mind that these may change from version to version, so don't take these ones as gospel if you're dealing with these specific applications!

Now, we need to take this information and utilize it, and this is where we seem to have come up with a way to defeat the hashing and permissions and HKLM-only crap that Microsoft are trying to foist on us. What we are going to do is delete the user's default file extension handler from the Registry as the user logs in, but write the filetype into HKCU\Software\Classes\.extension. Our testing showed that if you remove the entry from the FileExts key, it checks HKCU\Software\Classes for the filetype it should use.

Tools-wise, you could do this with a script (a very rough and ready sample is given a little later), but given that I have in the past done a lot of AppSense stuff, it made sense for me to leverage the power of DesktopNow to test this foremostly. Naturally, there is a whole ecosystem of products or scripting languages you could use to achieve this on XenApp - pick your poison as necessary!

I put this in the Desktop Created trigger but this was probably not necessary - I am fairly sure it should run just as well in Pre-Desktop.

Firstly I created a Condition for each of my AD security groups


Next, inside of each Condition, I nested a couple of Actions. The first was to delete the entire key that referred to the user-defined settings


Despite the Deny permission I wrote about earlier, this entire parent key should be accessible to the user, so there's no need for elevated access.

Next, we simply set the default value in HKCU\Software\Classes to the required filetype. Be very careful here - you need to use the AppSense Action for Registry | Set default value rather than Set value. So for our first group, we set up SumatraPDF in this area


The second one gets Adobe Reader


And the third, Foxit Reader


So our whole nested set of Actions should now look something like this


If you wanted to do this with a script, you could maybe experiment with a few AD logon scripts using Security Filtering to scope the logon script to the AD groups in question. PowerShell would be the easiest way, but if you wanted a quick bit of batch, this sort of thing should suffice (lines may wrap)

reg delete HKCU\Software\Microsoft\Windows\CurrentVersion\Explorer\FileExts\.pdf /f
reg add HKCU\Software\Classes\.pdf /v "" /d FoxitReader.Document /f

Note that this is for Foxit Reader - substitute the required filetype as necessary

So now we need to deploy this to our XenApp server and log on our test user. Firstly, we will make him a member of the first group (and ensure we have a PDF file on the desktop so that we can see the association straight away). Firstly, he should be assigned SumatraPDF as the reader of choice. Let's see...


...and it looks good. Now let's try with our user in the second group, so he should get Adobe Reader...


...and it looks excellent, another good result. Finally we will create a new user and assign him to the third group, where he (or she!) should get Foxit Reader...


...which is exactly what it does. Brilliant!

Just for posterity, I spun up a second XenApp 7.6 system just to ensure that all of the "testing" (which broadly correlates to us deleting stuff and seeing what we'd got around) hadn't given us some Frankenstein-esque system that was simply playing ball just for the hell of it. Apart from having to make sure the software application versions matched the filetypes (trying to use the AcroExch.Document.DC filetype with Adobe Reader XI resulted in some awkward moments - it should have been AcroExch.Document.11!), it all seemed to work very well.

The issue with "roaming" selected FTAs from machine to machine, however, is one that we will have to visit in another post, however, hopefully the pointers here might have some mileage for this problem as well in the meantime. Duncan mentioned that he was looking at a scripted way of doing this (although I'm sure he's very busy with other stuff), but it's definitely something that also needs addressing.

Anyway - hopefully this should provide a method of applying per-user FTAs for those of you who have to deal with this on XenApp or XenDesktop systems (or RDSH, for that matter). It certainly did the trick in my lab - I'd be interested in finding out if it works in the wild, because the interplay between the various areas of the Registry and the file type handlers certainly makes for a fairly complicated subject.

Big kudos due to Duncan for taking the time out to dive into this - hopefully we won't have to go down this route again! :-)

Update - I built a third XenApp server, just to be sure, and this time the solution wouldn't work until I removed the Registry key HKLM\Software\Classes\.pdf. If you have problems with this, this may be something to check in your gold image/template/however you deploy a server.
↧

QuickPost: Logging XenApp server session durations

October 21, 2015, 3:55 pm
$
0
0
I'm knee-deep in a revisit of the Internet Explorer 10+ Cookies and History debacle (and I'm already wishing I hadn't!), so it's an apt time for a QuickPost just to stop me from going completely and utterly insane. I had a request recently to log the durations of XenApp server sessions during a PoC. Now, this is something that I'd normally do by using a report from EdgeSight/Director or other monitoring tools such as Lakeside SysTrack or ControlUp, but sometimes this can be fiddly or time-consuming to set up, or you may not even actually have the tools required. The requirement was fairly simple - create a comma-delimited log file that simply recorded the userid, date and duration of the session which would then be loaded and manipulated in Excel - so I set off to quickly knock one up. As a requirement, it's not that strange - I've worked in a few places where staff and management wanted to know how much usage PoCs and pilots were actually getting, so it is fairly relevant.

Breaking the task down, what do we need to do?

1. Record the actual date and time of logon, and store this somewhere
2. Record the date and time of logoff
3. Compare the stored logon time to the logoff time and create a Session Duration time
4. Write the user info, the date, and the Session Duration to a file in a network share for perusal

OK. Tools-wise, we've gone for PowerShell (great thanks to Duncan Murdoch for helping tidy this up from my rough-and-ready batch/PS combo I originally went with). I used AppSense DesktopNow to do the tooling - however, if you simply want to run the scripts as Group Policy Logon and Logoff Scripts they should work just as well without any alterations. However, if you do it through GPO, make sure the PowerShell execution policy is set correctly to allow your scripts to run.

Firstly, when the user logs on, we need to simply extract the date and time of their logon and store it somewhere. We've elected to write it to HKCU in a key called ~Custom. We also need to check that this key exists before writing it.

$date = Get-Date

$regpath = "HKCU:\Software\~Custom"
$name = "LogonTime"
$value = $date

if (!(Test-Path -Path $regpath))
{
    New-Item -Path $regpath -Type String
    New-ItemProperty -Path $regpath -Name $name -Value $value
}
else
{
    Set-ItemProperty -Path $regpath -Name $name -Value $value
}

That's all we need to do for the logon section.

When the user comes to log out of their XenApp session, we have a bit more work to do.

First of all we need to repeat the gathering of the current date and time once again and store it in a variable

$LogoffTime = (Get-Date)

Then, we need to set up another variable which simply stores the date, as Get-Date gives us both date and time

$Date = (Get-Date -format "dd-MM-yyyy")

Next, we have to retrieve the LogonTime information which we stored in the Registry earlier

$regPath ="HKCU:\Software\~Custom"
$regvalue ="LogonTime"

$LogonTime =Get-ItemProperty-Path $regPath -Name $regvalue

And next we need to compare $LogonTime with $LogoffTime to generate a $SessionDuration variable, and then cut that down to a single line for perusal. Luckily, PowerShell has the New-TimeSpan cmdlet which can do this for us (isn't PowerShell great?)

$SessionDuration = New-TimeSpan -Start $LogonTime.LogonTime -End $LogoffTime

$data ="{0:c}"-f $SessionDuration

Finally, we have to take all of the data we've gathered into these variables and spit it out using Out-File to the csv file which we've got on the network. This is where my PowerShell probably looks clunky and rudimentary (lines will wrap), but hey, it works :-)

$data1 = $data.Split(":"); $hours = $($data1[0]); $minutes = $($data1[1]); $seconds = $($data1[2])
"$env:USERDOMAIN\$env:USERNAME,$date,$hours hours $minutes minutes $seconds seconds"| Out-File\\UKSLDC001\FileStore\Logs\XenAppServerLogs.csv-Append

Needless to say, your users will need Write access to the share and filesystem where the log file resides.

Also, it would be prudent to remove the LogonTime entry from the Registry that we wrote at login, as next time the user logs in it will need to be recreated. Again, use tools like AppSense or a scripted command to achieve this part


Naturally, now it is time to test! Let's log a user on to our XenApp PoC server published desktop, use a few applications, and then log back out. Note that this should work equally well for published applications and not just desktops or VDI sessions. Let's check our logs...


...and as you can see, we have a nicely-delimited format to pull out the details for the user, the date, and the logon duration.

Big credit due to Duncan Murdoch for helping me tidy up my dirty scripting (and a big middle finger to Graeme Cowie who said even Rupert Murdoch couldn't sort out my scripts ;-)). Also Carl Webster for, as usual, pointing me in the right direction. Obviously, I only tested this on English UK date formats, so please test it thoroughly before using it yourself. But hopefully this will help any of you out there wanting some quick and dirty logon duration stats pulled out from your systems during PoC phases.
↧

QuickPost: Launching StoreFront Internet Explorer sessions maximized

October 26, 2015, 3:35 pm
$
0
0
I'm still not finished with these damned Cookies and History...however, I think I've found a way to reliably persist them, with some jiggery-pokery involved. So while I collate all the results, time for another QuickPost of something I find myself doing fairly regularly but always having to look up - how to launch IE (StoreFront sessions, specifically) fully maximized.

It seems to be quite popular in a lot of enterprises I work with to launch the StoreFront web session maximized, to allow users to see all of their available and featured applications full-screen, but without the loss of toolbars or controls. Actually, it's not just a Citrix StoreFront/Web Interface thing, to be fair - many of the places I consult with who like to auto-launch their intranet pages as a portal for their users also tend to want it running maximized as well. 
 
Unfortunately, my old friend Internet Explorer has traditionally had so many entry points (shortcuts, system icons, typed URLs, links in other documents) that it's quite tricky to be able to consistently launch it in a maximized state (maximized to the screen, rather than the full-screen F11 IE, which is easy enough to do with Group Policy). Microsoft's advice is normally to change the properties of the shortcut that launches it by following this process:-

Right click on the desktop and create a short cut to "Program Files/Internet Explorer/iexplore.exe"
Right click on the short cut and then select Properties.
Click on the tab "Shortcut" and then change the value in the Run command to "Maximized".
Click Apply.
Now Internet Explorer will open in the maximized state when you click on the short cut to iexplore.exe

Unfortunately this a) doesn't work in the latest versions of Windows, and b) only worked on the particular shortcut anyway, meaning that if you opened IE by any other method it wouldn't graft. Another popular suggestion on the Intertubes was always to "close maximized IE whilst holding down CTRL". This actually DOES work, but getting the user to do this was always the weakness - ideally, we're looking for something that can do this for the user without any interaction.

What I've always done is simply import in a particular Registry value that deals with the placement of the IE window (if I've missed some spectacularly easy way of doing this, I'm sure someone will let me know, but I definitely couldn't find anything first time I tried it!) We will set up an Internet Explorer session firstly that runs when the user logs in, to take them to the StoreFront page. As usual, we're tooling with AppSense DesktopNow, but you can use anything you like.


So when we log in (to a Windows 10 client - for my sins I am testing everything on Windows 10 now, client-wise), we see this


The easiest way (in my knowledge!) to make this run maximized is simply to add a binary Registry value to HKEY_CURRENT_USER. Best way to deal with binaries is to import a Registry file into AppSense DesktopNow or (if not on AppSense) just use the regedit.exe command directly (or some PowerShell if you're ultra-cool and leet). The content for the .reg file is shown below

Windows Registry Editor Version 5.00

[HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\Main]
"Window_Placement"=hex:2c,00,00,00,02,00,00,00,03,00,00,00,ff,ff,ff,ff,ff,ff,\
  ff,ff,ff,ff,ff,ff,ff,ff,ff,ff,24,00,00,00,24,00,00,00,a8,03,00,00,7c,02,00,\
  00

This should hopefully be all that you need. We will add this to our AppSense configuration (preferably before we launch IE!), and now we see


a nicely maximized StoreFront interface. It doesn't matter what resolution you're running in (I've tested several different ones), it always seems to open maximized. Obviously setting this means that any subsequent IE windows will open maximized anyway (unless the user alters them), but that's never seemed to be much of an issue.

So there's a nice and simple little tip for something that always seems slightly harder than it possibly needed to be - unless there's a glaringly obvious way I've been missing for all these years :-)

As promised, update to the Cookies and History series by the end of this week - and hopefully some more Windows 10 fun as well.
↧
Viewing all 178 articles
Browse latest View live
Search