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

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!
↧
Search

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.


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 :-)
↧
↧

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 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
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.
↧
↧

Persisting IE10 cookies using AppSense DesktopNow

January 6, 2015, 5:08 am
$
0
0
On a couple of occasions now I have done some work with Ben Whitmore (@byteben) down in the flatlands of Norfolk. The last time I was down there, we were doing an upgrade to AppSense EM 8 FR 5. Unfortunately there was something of a disaster during this, and we found there was an upgrade issue when endpoints were using Offline Mode, which effectively left us sans Personalization for a lot of users the next day until we implemented a workaround. Thankfully, AppSense have fixed this issue - details in this TechNote - in SP1 for EM 8 FR 5.

However, a further issue that came to light post-migration was the way that IE10 (and higher) handle cookies. I had a lot of back-and-forth emails with Ben regarding this, and one word that came up repeatedly in both emails and Tweets was the highly-appropriate term "minefield".

Traditional cookie handling

There have always been two main camps for cookie handling in DesktopNow - Folder Redirection, and Personalization Server. Personally, I've always preferred to redirect them onto the network, but some opt to capture them into Personalization. There's no right or wrong here - it's whatever works best for you.

So let's remind ourselves of how cookies should work. I'm running a published desktop on a XenApp 6.5 server with Internet Explorer 8 as my browser (stop laughing at the back - it's the default installed browser on 2008 R2), using a mandatory profile. I've got an AppSense EM configuration set up that redirects my Cookies folder to my home drive on the network.


When I go to a website that has a cookie warning (which seems to be just about every single one these days), we will see something like this


Naturally, clicking on Continue should make the warning go away and store the cookie in our Cookies folder, which will then be persisted because of the folder redirection. If we were putting {CSIDL_COOKIES} into Personalization Server, you'd also expect the same result. Just to verify this, I will log out of my XenApp session, make sure that the profile no longer exists on the server, and then log back in and try the same website.


Excellent - that's exactly the behaviour we are expecting. The cookies are persisting in our redirected folder, users aren't bothered by multiple prompts - all is good. The behaviour is the same in IE9 as it is in IE8, no issues are observed.

Now let's "upgrade" our browser to Internet Explorer 10. To do this on Windows Server 2008, you need to have SP1 installed.

Once the installation is done, let's go to the BBC website again. The "cookie warning" has returned! Is it just because we've upgraded our browser? Let's click Continue again and see what happens....


Damn! For some reason, cookies don't persist properly in IE10 using the Folder Redirection method. So, just what is going on here?

Environment Manager 8 FR 5

Now, those of you who've dared to do the upgrade to the latest version of AppSense DesktopNow EM will know that in your Windows Settings Groups, there are specifically defined settings for IE10 Cookies. Clearly something has changed under the hood!



If you read the article at https://www.myappsense.com/Knowledgebase/TN-151164.aspx (login required), you will see that indeed there has been a change. The Personalization Group needs to be utilized, and it captures the following Registry keys and folders:-

HKEY_CURRENT_USER\Software\Microsoft\Internet Explorer\DomStorage\
{CSIDL_LOCAL_APPDATA}\Microsoft\Windows\WebCache
{CSIDL_LOCAL_APPDATA}\Microsoft\Internet Explorer\DOMStore
{CSIDL_LOCAL_APPDATA}\Microsoft\Windows\History
{CSIDL_APPDATA}\Microsoft\Windows\Cookies
{CSIDL_PROFILE}\AppData\LocalLow\Microsoft\Internet Explorer\DOMStore

OK, so it's a change, but let's give it a go. After all, they've included the functionality (which presumes some testing done, yes?), so it should work...

The Windows Setting Group is pre-defined, which is handy, but please bear in mind this fact - you can't edit the pre-defined Windows Settings Groups at all. This is rather annoying if you want to change any of the settings (which you may well want to) - it might be easier to copy the pre-defined Windows Settings Groups and create your own, editable ones.

Anyways, let's link the pre-defined group to our Personalization Group



Nice and simple, eh? So let's now perform our test again and see what happens. After we click the Continue button and log out, there is data in the Personalization Server database...



...but unfortunately, this solution doesn't seem to work very well at all. Some websites retain the cookie settings OK - but some don't. Additionally, your cookies may be preserved on some sessions - then at next logon they're all gone again, and putting up the prompts that you've already responded to.


It's unclear if this "loss of cookie settings" has any pattern to it at all. As we are using a mandatory profile which is obviously discarded at logoff (the "delete cached copies of roaming profiles" GPO is in use), there is no actual IE-specific Personalization going on (all we are doing is the IE10 cookies via Windows Personalization), and we're visiting three different websites to see if the cookie message appears (just in case it was a site-based problem), it is clear that the this isn't working as we are used to. Hmmm. I can see how this would become an almighty pain in the backside to users - it doesn't stop you working, but it's a frustrating, nagging issue that you know should go away.

The only pattern I can discern is that it seems to be almost every second logon where this occurs, rather than each one, making things even more random. And the history of visited websites seems to disappear at the same time too. Clearly the AppSense solution has captured some of the pertinent data - but it isn't persisting correctly. So we've foregone the old reliable Folder Redirection solution for putting it into Personalization directly - yet neither of them seem to work satisfactorily!

Something else is going on here - something that the AppSense-provided solution doesn't quite cover. What could it be?

Digging time

As usual, the Intertubes will be involved in the research segment of attacking this problem.

Firstly I visited Microsoft's update servers and made sure I was fully patched (I was fairly sure I was - the patching process took several hours and hung my VM twice). I also ensured the latest Citrix hotfixes were present (shot in the dark, but you never know). There is no antivirus or similar product running on the test server - just a bare bones 2008 R2 install with XenApp on top.

Now, research at this precise moment would throw up an AppSense technote regarding this issue - https://www.myappsense.com/Knowledgebase/TN-151371.aspx (login required). I'm fairly sure this is probably a response to Ben's reporting of the issue or someone else's. However, it does provide a nice description of the issue (which I will summarize).

It looks like Microsoft decided, at some point, to move from IE's old way of tracking this sort of data - index.dat files - and replace them with a proper database file called WebCacheV01.dat. I'm assuming this was done to take advantage of modern compute and simplify coding, as well as improving performance. The AppSense article tells us that "when Internet Explorer is launched, the files under the %LocalAppData%\Microsoft\Windows\WebCache directory are locked...these files are in use during the Internet Explorer session and for some time after Internet Explorer has exited".

It's a Scheduled Task, of all things, that keeps the damn handle open. The task in question is Task Scheduler Library > Microsoft > Windows > Wininet. What the task is intended to do is something of a mystery - it's name is CacheTask, and trying to edit the "Custom Handler" under the Actions tab in Task Scheduler throws up this



Yes, I have no idea what this does - and information from Google is also sadly lacking. There's more than just this task with "mystery" properties - I can only assume some of the Windows Automatic Maintenance jobs are done by these things. It would be interesting to find out what they're really for, but I'm not interested in understanding it's purpose right now - just to prevent it from interfering with those cookies!

Well, as luck would have it, there's a short blog post from Michael Obernberger describing this exact issue - and, more importantly, an AppSense configuration available for download. Don't you just love community?

Breaking the open handle

Now, Michael's configuration (there's a link in his article - I've also reproduced an EM 8 FR 5 version of it at the end of this one) is nice and simple. It uses a bit of PowerShell tied to some AppSense EM Mirror Folder Actions. Essentially, in the Logon trigger you stop the task, Mirror the folder data in from the network, and then restart the task. And then during the Logoff trigger, you stop the task and Mirror the folder data out to the network. Dead simple!

You could maybe use Internet Explorer Process Started and Process Stopped as the trigger points, but given that IE is tied closely to the operating system many people opt to deal with it at logon and logoff.

If you wanted to get clever, you could actually Mirror the cookie data to a local folder, and then capture that into Personalization Server as the process exits. The advantage you would get from this method is that you could then use the Personalization rollback features and reduce reliance on network shares, but that would be slightly more complicated. However - the WebCacheV01.dat file can get big, and if it did I wouldn't fancy the overhead of putting hundreds or thousands of multiple copies of it into Personalization Server.

But.....unfortunately, in this case, this doesn't work either. What's going on?

Redirection+

What is actually needed, it turns out (in my testing anyways) is to, rather strangely, combine the old style with the new. The only way I could get this to work was by not only configuring the settings defined above (stopping the Scheduled Task and copying in the required file), but also by defining the Folder Redirection for Cookies. Reading Michael's article back that I mentioned earlier, I think that this is what he was alluding to, it just wasn't spelled out particularly clearly. But if you remove either of these parts - be it the part that copies in the .dat file or the Folder Redirection - then the roaming of Cookies will stop.

Now, adding the Windows Personalization Group for IE 10 Cookies isn't necessary for this to work - in fact, it seems to be completely extraneous (although see the note in the table below). The key is combining the Folder Redirection with the capture of the webcachev01.dat file, which can only be done when the Scheduled Task is stopped. In light of this, I won't be using the AppSense-provided Windows Personalization Group at all - and given the size that the webcachev01.dat file can get (32MB after two logons), this is probably a good thing, speaking frankly. This may change as AppSense try and address this issue, but for the moment, this is the only way I can find to make these cookies persist.

Summing up

To summarize, what I found was (where WPG is Windows Personalization Group for IE 10 Cookies and History, Copy Task is the "stop scheduled task and copy webcache folder" Actions, and Redirection is Folder Redirection of Cookies):-

Redirection alone - fails
Copy task alone - fails
WPG alone - fails
Redirection + WPG - fails
Copy task + WPG - fails
Redirection + copy task + WPG - works (NOTE - this combination may be required for certain websites however)
Redirection + copy task - works


The node with the Actions required to bring in the persisted Cookies at logon
The node with the Actions required to hive out the persisted Cookies at logoff

The key to grabbing the webcachev01.dat file lies in using PowerShell to stop and start the Scheduled Task - the code used is shown below

schtasks /end /tn "Microsoft\Windows\Wininet\CacheTask" | Out-Null

schtasks /run /tn "Microsoft\Windows\Wininet\CacheTask" | Out-Null

There is a configuration available here that shows how this should be set up (EM 8 FR 5 version) - don't forget, obviously, to change the paths for the server and share to reflect your own environment!

I've tested this on three separate websites, twenty sessions in succession, and it seems to work on each. In each case I checked that the profile was completely removed before logging back on, and no other IE Personalization was taking place (in fact, no Personalization at all). However - I have only tested this on Windows Server 2008 R2, and I also wanted to test this on Windows 7, but Microsoft's licensing weirdness means I can't get a trial version of Windows 7 any more for my lab.

Also, it is worth noting that in Windows 8.1 (and Server 2012 R2, for that matter), Microsoft have back-tracked on this. Configuring AppSense EM to use simply the Folder Redirection method works perfectly in this case. Of course, this is IE11, and it may also turn out that upgrading to the latest version on Windows 7 or 2008 R2 may also do the trick for you (if you dare!)

Finally, this article only deals with Cookie persistence - and as I am sure you are aware, the AppSense-provided Windows Personalization Group also mentions History persistence. This is something I am going to tackle in my next article, if only to stop this one expanding too much!

Credits

Thanks to Michael Obernberger for the PowerShell and insight from his article that allowed us to focus on the core of this issue, and also to Ben Whitmore for providing plenty of relevant links and frustrated testing.

Update 07/01/15 - this method worked on the three websites I tested without any problems at all, but as I found out this morning, it doesn't work on a few odd websites (but adding the Windows Personalization Group in there as well should make the issue go away). I will try and find out why this happens to certain sites - in the meantime, I can only conclude that Microsoft's cookie implementation in IE10 is, to be frank, a steaming pile of horse poo. Avoid.
↧

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 PowerShell we will use is this (lines will probably have wrapped):-

$ieVersion = New-Object -TypeName System.Version -ArgumentList (Get-ItemProperty 'HKLM:\SOFTWARE\Microsoft\Internet Explorer').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)


Hope that's helpful - now I'm heading back to my battle with Cookies and History :-(
↧
Search

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
↧

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

February 18, 2015, 8:33 am
$
0
0
In the first part of this article we looked at the performance of the major Internet Explorer versions with a variety of platforms and persistence methods. In this second instalment, we will measure the same performance metrics against two of the more popular "lite" user environment management tools - Citrix's User Profile Manager and Microsoft's User Experience Virtualization, herein referred to as either UPM or UE-V.

In part #3, I will take a look at some of the other UEM solutions out there and how they manage this issue - Immidio, ProfileUnity and Scense are the ones on my radar currently.

Again, I will repeat my disclaimer about this testing being done in my own personal lab, and how it may not necessarily reflect what you see in your own environments, as the applications, infrastructure and users will no doubt differ radically.

Before we get down to business, it might be prudent to do a quick recap on the platforms, software versions, persistence methods and tests we will be using to measure this.

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. (Actually I now have a copy of Windows 7, so there may be updates to both of these articles in the near future to cover it off)

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. For the persistence methods that leverage Folder Redirection, we have configured a Group Policy Preference to enable this.


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 are only using three persistence methods in this case.

Method 8 - Citrix UPM (native)

UPM has been configured with a base template profile and a default configuration, as shown in the export file here. No folder redirection is in place - all of the user settings are being managed centrally via UPM.

Method 9 - Citrix UPM (redirected)

This is configured identically as above, except Folder Redirection has been configured via GPP for the History and Cookies folders. It may appear that the UPM configuration we have used is working at cross-purposes to this (ideally, if using folder redirection, you should exclude the redirected folders from UPM processing), but for the purposes of this testing, the performance overhead incurred was not really a concern.

Method 10 - Microsoft UE-V (redirected)

UE-V was configured with a mandatory profile identical to that used in part #1, and the default templates loaded to ensure that Internet Explorer settings were being saved. The store was directed to a file share on the domain controller.

It is interesting to note that Microsoft make some claims about Internet Explorer settings with UE-V, such as "Internet Explorer does not support copying cookie files or other cache data from one machine to another". So, if we were an enterprise looking to use UE-V to roam our users' settings in this way, what would be the first thing we think of? Well of course, it's our old friend Folder Redirection, so to attempt roaming of Cookies and History, we've redirected the folders. If you want to read the full article regarding UE-V and IE, it's linked here.

Method 11 and onwards

I've got hold of some other UEM products too - Immidio, ProfileUnity and Scense - but as I am rapidly losing the will to live, I've decided to hold off testing those until I can muster up the resolve to pen a part #3. Anyone else in the UEM space who might want me to test their offerings, feel free to send me a trial version (although I've no doubt you're capable of testing it yourselves).

Testing process

This is going to be identical to that which we used in the first part of this article, so there's no need to reproduce it again here.

Results

Well - how did the "UEM-lite" applications fare?

Internet Explorer 8 on Windows Server 2008 R2


Test 1Test 2Test 3Test 4Test 5 Test 6
Microsoft UE-V with redirectionPassPassPassPassPassFail
Citrix UPMPassPassPassPassPassPass
Citrix UPM with redirectionPassPassPassPassPassPass

The one oddity is that UE-V didn't roam History past the 48 hour period - in fact, a whole host of settings seemed to reset themselves to defaults at this point. However, the overall behaviour from IE8 that we observed in our first set of tests continues here - IE8 roaming is, for the most part, robust and reliable.

Internet Explorer 9 on Windows Server 2008 R2


Test 1Test 2Test 3Test 4Test 5 Test 6
Microsoft UE-V with redirectionPassPassPassPassPassPass
Citrix UPMFailPassPassPassFailFail
Citrix UPM with redirectionFailPassPassPassPassPass

The oddness seems to spread a bit here - a clean sweep for UE-V and an almost-clean sweep for redirected UPM, but UPM native choked on the History settings with what looked awfully like the (now very familiar) IE10+ "History inaccessible" issue, manifesting itself on IE9 for a change. For what it's worth, after resetting the file's system attribute it persisted better, but because this behaviour was observed on more than one occasion without resetting the attribute, I've still marked it down as a Fail in the results.

Again, this anomaly aside, IE9 backs up our earlier findings by roaming quite adequately in most situations.

Internet Explorer 10 on Windows Server 2008 R2


Test 1Test 2Test 3Test 4Test 5 Test 6
Microsoft UE-V with redirectionFailFailFailFailFailFail
Citrix UPMFailPassPassPassPassPass
Citrix UPM with redirectionFailPassPassPassFailFail

Now, some slightly more interesting results here. UE-V totally fails, compared to a total success on IE9. That's a marked difference in performance if you take it from IE9 to IE10 - a 100% drop!

The native UPM method does very well, only failing on the first test (Google cookie warning). As I've seen this fail quite a lot, I'm wondering if there's something peculiar about that particular cookie that makes it unsuitable for these tests (although some of the AppSense methods dealt with it no problem). A former colleague of mine, Stephen Faulkner, also indicated that they were using IE10 with the native UPM method and observing no issues.

But we're back to the same old story when you combine UPM with redirection - Cookies are working OK, but History is inaccessible (as it was also for UE-V, incidentally). The problem does, admittedly, manifest in a slightly different fashion (see below), but the net effect is exactly the same. Again, this may go back to the issue with the system file attribute, but why oh why is this happening in the first place? What's changed under the hood?

In this case the "Today" link actually appears rather than being blank, but when clicked on, nothing happens

Internet Explorer 11 on Windows Server 2008 R2


Test 1Test 2Test 3Test 4Test 5 Test 6
Microsoft UE-V with redirectionFailFailFailFailFailFail
Citrix UPMFailPassPassPassPassPass
Citrix UPM with redirectionFailPassPassPassFailFail

There are no differences between the IE10 behaviour and the IE11 behaviour, for these methods. Exactly the same results are produced - a total failure for UE-V, native UPM passes all tests bar the first, and UPM with redirection roams Cookies OK, but fails with inaccessible History.

Internet Explorer 11 on Windows Server 2012 R2


Test 1Test 2Test 3Test 4Test 5 Test 6
Microsoft UE-V with redirectionFailFailFailFailFailFail
Citrix UPMFailPassPassPassPassPass
Citrix UPM with redirectionFailPassPassPassFailFail

These three methods behave exactly the same on Windows Server 2012 R2 as they did on 2008 R2 when using IE11.

Internet Explorer 11 on Windows 8.1


Test 1Test 2Test 3Test 4Test 5 Test 6
Microsoft UE-V with redirectionFailFailFailFailFailFail
Citrix UPMFailPassPassPassPassPass
Citrix UPM with redirectionFailPassPassPassFailFail

And again, we have the exact same results on Windows 8.1 as the previous two platforms.

Findings

Again, we can see that there is a definite trend here. On IE8 and IE9, we get good or acceptable performance, even if we have to tread Microsoft's "that's not supported!" route by shoehorning Folder Redirection into the equation.

Update to IE10+, and the greens start turning to reds very dramatically. However, Citrix UPM in the "native" non-redirected method comes out of this quite favourably, showing that it can handle the under-the-hood shenanigans of IE10+ quite well. But as always, putting Folder Redirection into the mix post-IE10 results in failures - for both Cookies and History under UE-V, and for just History with redirected UPM.

If we put this into a graph format, we can see the reliability of IE under these tests dropping as we move to IE10/11, and then upticking slightly for IE11 on Windows 8.1. Sixty tests were done on each in total, and this shows how many actually passed.

IE Cookies and History reliability across versions

On Windows Server 2008 R2, updating to IE10 results in a just short of 50% drop in reliability of your Cookies and History retention, across the persistence methods we've tested.

So our conclusions are so far looking fairly similar to the previous article. UE-V comes with a disclaimer around Cookies and History, but it manages OK with redirection until IE10 comes along, at which point it sinks without trace. UPM handles the IE10 nastiness very well - unless you've combined it with redirected folders, in which case you can kiss your History goodbye. Cookies, though, have always been one of UPM's strong points, and it proves this by consistently retaining them throughout the tests, no matter how they were saved or what platform/version it was being run on.

Summary

Our previous article showed that AppSense EM, in certain configurations, could save your Cookies and History reliably. This article adds Citrix User Profile Manager to that mix, as long as you avoid Folder Redirection. As I mentioned before, IE10+ kills any chance of making redirected Cookies and History working. And before Microsoft jump in with the "we said it wasn't supported" excuse, it's just not good enough. I'm not going to head off on another rant, but in a multi-user modern environment, we shouldn't have to be jumping through hoops to try and roam basic user settings like these.

Stay tuned for part #3, where I will verify a few more UEM vendors against these tests. I'm also going to put together an article where it shows you how to quickly migrate between browsers using DesktopNow - on the back of highlighting these problems, I've had a couple of requests to document this.
↧

Set up AppSense DataNow appliance in a home lab - a quick guide

March 4, 2015, 3:33 am
$
0
0
I've been sadly neglecting AppSense's DataNow product on this blog, but given that I am in the middle of doing a big comparison article on EFSS (Enterprise File Sync and Sharing) software, I thought now would be a good time to change that slightly. For the aforementioned article, I've been having to set up a lot of EFSS software to run in my lab. So for anyone who fancies doing it also, here's a quick guide to setting up the DataNow appliance in a lab environment.

Hypervisor

I'm using the latest version of the appliance (3.0.3.1, at time of writing), and I am running my lab on Windows 8.1 client-side Hyper-V (on my new PC packing 48GB of RAM, which just feels so strange given that my first PC had only 4MB). On the AppSense website you will see that there are appliances for Hyper-V and ESXi/VSphere, but they should run equally well on client Hyper-V or VMware Workstation. On Windows 8.1 Hyper-V, you will need the 2012 R2 appliance version.

Lab pre-requisites

Given the way that DataNow works (leveraging on-premise storage to create a DropBox/OneDrive/ShareFile type of collaboration), you will also need another virtual machine running in your lab - an Active Directory domain controller. Whilst some people may say "yeah, right!" at this prospect, if you're serious about testing and developing your skills, then a properly-equipped home lab, in this day and age, is very much a pre-requisite. Cloud services haven't cheapened enough for me to (yet) think about hosting my setup in Azure or AWS (a lab with 48GB of RAM running pretty much non-stop and doubling up as a media server with over 8TB of storage would cost a small fortune currently), so running it in-house (so to speak) is currently the most cost-effective mechanism. I also find that running a lab keeps your day-to-day skills up-to-date - without it, I wouldn't keep getting my hands dirty with network and DNS problems, amongst many others. So get down to it and quickly spin yourself up a domain controller!

Next you will need to get the DataNow appliance downloaded from the AppSense website, as appropriate for your hypervisor. Whilst this is ticking away, we can probably start on some other pre-requisite tasks.

Other pre-requisites

Firstly, set up a static DNS record for the DataNow appliance in your internal network. DataNow can't use DHCP addresses, so an address that is outside of your DHCP range needs to be set up specifically for it.


It would also be a very good idea to set up a dynamic DNS service (unless you have an external static IP address, which is more and more uncommon these days). If you don't set up dynamic DNS, then you will have to work out your public IP and connect to it when you're accessing your DataNow appliance externally - expect to spend a lot of time Googling "what is my IP?", especially if it changes in-session. There are good free dynamic DNS services out there - No-IP being the one I use since DynDNS became a paid option. It doesn't take long to sign up and it will save you a lot of bother, so it makes sense to set it up at this stage.


Also ensure that users who will be accessing the DataNow appliance have a home directory set in your AD, as this is how files will initially be accessed.



By this time, unless you live in Norfolk, your appliance should have finished downloading long hence. Don't forget to download any applicable hotfixes also (see image below).



Once your downloads are finished, it is then time to import the appliance into your hypervisor.

Configuring the appliance

Once you've extracted the zip file(s), the appliance needs to be set up in your hypervisor. On Hyper-V, I open the management console and choose the Import function, before selecting the folder where I have extracted the DataNow appliance files to.


Click Next


Click Next


Click Next again at the Choose Import Type screen


By default the DataNow appliance requires 4 virtual processors, but this is neither necessary (nor possible, in my case). The DataNow appliance will run just fine in a lab environment with 1 vCPU, so set the option to 1 and click Next again.

Click Finish at the final summary screen, and you will see that your virtual machine has been imported successfully.


The appliance will also use, by default, 4GB of RAM. Even if you have oodles of it, it makes sense not to overcommit, so we will reduce it down to 2GB by right-clicking the VM and choosing Settings


Also, the machine is not connected by default to a network, so attach a virtual NIC at this stage too. I have the Hyper-V virtual switch connected directly to the host's external network, which makes it simpler from a troubleshooting perspective, but be aware there may be security considerations around not putting your machines into a separate virtual network.


Now we can switch the VM on and start some configuration.

Initial configuration

First thing to do is connect to the console of the appliance


Pressing F2 will bring up the following box


The default password is AppSense (case-sensitive) - you will need to change it at this point.


Next, you should see the base menu. Select Configure Networking from the options available.


Give the appliance the desired hostname, and assign the IP address to the appliance that you set up in DNS. Make sure that the subnet mask is correct and the default gateway points to the correct routing device on your home network (DataNow needs to be able to communicate with external clients, don't forget!)


Once you've done this, the appliance needs a restart, so the Reboot option would be a good idea :-)

Web configuration

After the restart, the appliance should now be contactable via the web services running on it. For the admin interface, you need to browse to https://ApplianceName:8443


The username is appliance and the password will be whatever you set it to during the console configuration section.

Next you will see a load of alerts warning you about configuration items that need to be completed. But first, let's install any patches we may have downloaded. Click on the Version link.


Click on the Browse button, and find the patch you downloaded (which should have extracted to a .bin file). Once selected, click on the Upload Patch File button.


Next, click on Apply Patch Now. This will cause the appliance to restart. If you're paranoid, it may be a good idea to snapshot/checkpoint the system prior to patching, but I haven't bothered.


Once the restart is finished, you should see upgraded components



Next, you need to deal with the alerts you saw on the initial screen. Firstly, we need to click on the link to upload a license file. You can request a 30-day trial from the AppSense website. If you have a full license, you will need to use the .txt version, rather than the .pdf.



Then it's on to DNS settings. Click the link and choose the Edit button from the DNS screen. The Edit button can be a bit temperamental - you may need to click it a few times to get it to activate (although this is probably something to do with my old pal Internet Explorer). Input the required values (you shouldn't need to put anything in for WINS, unless you've got a lab from the dark ages, or you use WINS for home drive settings)



On the list now should be Active Directory settings. Click on the link and click Add New, before setting it up as required.



Interestingly, I was stricken with this error initially (see below) when trying to save the AD details



In the DC's security log, I could see a successful network logon from the account I specified, so there was clearly no problem with contacting and validating against the domain. Something else was obviously causing the issue.

To get around this, I had to disable the following setting from the Default Domain Controllers GPO - Computer Config | Windows Settings | Security Settings | Local Policies | Security Options | Domain controller: LDAP server signing requirements. I needed to set it to None or Not Configured (shown below)



What security considerations disabling this raises I'm not sure, but it certainly worked a treat once I had it done (a gpupdate may be required to sync the new setting).

Finally, and most annoyingly, the next requirement is for a certificate. Those of you who know me may be aware that I passionately hate three pieces of tech - Java, Internet Explorer 10+, and certificates. You can run DataNow without a proper certificate - but given that the DataNow client won't connect without it, it's kind of a pre-requisite, unless you want to use the web version permanently.

In the interests of keeping this easy(ish) I installed the Active Directory Certificate Services role on my DC along with the role services for CA Web Enrollment and Network Device Enrollment Service. Those of you that are less certophobic than myself may find using another enterprise CA solution much easier.

Without getting too deep into the certificate side of things, I generated and installed a certificate by following the instructions in the online help. You will need to tailor this process based around your CA solution.

Testing this worked OK after installing the certificates - as long as I disabled the Avast antivirus which is installed on my host machine. For some reason, Avast is opting to mark the certificates as untrusted (see below for the certificate error reported from the web site)



If we disable the Avast processes, though, the certificate appears all well and good


This is odd, but an internal certificate error isn't that much of a big deal - we can simply click through it, and external access is probably the key part of the product anyway :-)

Finally, click on Configuration in the admin console and choose Admin Users. Add in any required administrative users from your domain, if you wish to use a separate account to administer the appliance.



Once all these steps are finished, you should see a nice green interface on the initial screen of the admin console



Network configuration

Now that we've got the DataNow appliance running (you can connect to the standard user web interface by browsing to https://appliancename), we need to make it available externally.

The DataNow appliance listens for connections on port 443, so what we need to do is set up your home router to forward connections onto the DataNow appliance on the correct port. Obviously your device will be configured differently depending on what it is, but the port forwarding principle is the same - pick an external port, and forward it onto port 443 of the DataNow device (specified normally by IP address). As I connect from a lot of places and sometimes there are some restrictive outbound firewall rules, I've opted to forward my router's port 443 onto the DataNow appliance's port 443. Below is a configuration example from my BT router.





Once you've done this, you should be able to connect to the DataNow web interface by connecting to https://DynamicDNSaddress-or-PublicIPaddress (if you've specified a port other than 443, don't forget the :portnumber on the end!) from an external location. If you've configured your certificates and port forwarding correctly, you should be able to log in using your domain credentials and see the contents of your home drive.



Client configuration

Now, if you want to install the full DataNow client on an external computer and access your files and folders, firstly you will need to install the exported certificates you generated earlier into the Trusted Root Certification Authorities for the Local Computer physical store (see below).



Once the certificates are installed correctly, you will need to download the relevant client from the AppSense website and install it. After it installs, you should see some configuration dialogs.



First fill in the name of the server (either use your dynamic DNS name or the public IP) and choose the local location of your DataNow folder.



Next simply supply your username (with domain prefix) and the password to accompany it.



The server will log on (assuming everything is configured correctly) and you will then see DataNow synchronizing the items from your remote file storage into your local DataNow folder! Cool!



Mobile synchronization

The DataNow client also runs on OSX, Android, and iOS, so you can sync up your files to any devices running these operating systems. Simply install the client from the AppSense website and you should be good to go, with the same minimum fuss we saw for the Windows client.

Summary

So, that covers a quick setup of DataNow in a home lab situation. You can use your DataNow appliance for PoC or demonstration purposes, or even as a full-featured EFSS solution for your own use.

Don't be fooled by the limited usage we've demonstrated in this article - there are lots more additional collaborative features in DataNow than simple single-user folder synchronization. We will cover these in a future post.
↧

QuickPost - XenDesktopServerSetup crashes when installing XenApp or XenDesktop 7.6

March 17, 2015, 7:47 am
$
0
0
Today, whilst trying to put together a XenDesktop PoC system, I was confronted with an error that had me stumped for quite some time.

The installer (AutoSelect.exe from the XenDesktop 7.6 installation files), seemed to run OK at first



I selected either XenApp or XenDesktop, it didn't matter which was used



But as soon as I clicked on Delivery Controller, at first I was experiencing a crash of the installer itself, shown below


Looking in the event logs revealed a .Net-related error


Trying various common remedial methods - using Run As Administrator, pre-installing the .Net features, etc. - didn't seem to make any difference. Hmmm!

Next stop was to dig out the XenDesktop installer log from its hiding place deep in %LOCALAPPDATA%\Local\Temp\Citrix\XenDesktop Installer\XenDesktop Installation.txt and check for errors. The AutoRun part of the installer also has a log, found typically (in an RDP session) at %TEMP%\Citrix\XenDesktop Installer\AutoRun.log, but in this case that was completing successfully.

Parsing the XenDesktop Installation.txt file showed the following

$ERR$ : AutoRun:Unable to record application type in the registry, error Access to the registry key 'HKEY_LOCAL_MACHINE\SOFTWARE\Citrix' is denied

This seemed strange, given that we were using a local Administrator account, so I went into the Registry, created the key HKLM\Software\Citrix key manually, and made sure my account had Full Control permissions to the key.

Running the Delivery Controller installer again, this time it didn't crash. But another problem now manifested itself - the installer screen would simply sit with the animation moving (highlighted below), but never actually progressing any further


Stranger still!

I went in again and looked at the XenDesktop installer log. This time it was progressing further, but coming to an end at a particular point. The entire log is reproduced below. There are two errors near the start (shown in bold), but the installer seems to continue afterwards before coming to a halt in some sort of pre-requisite check

Date: Tuesday, March 17, 2015
Application version 7.6.0.5019
Running from C:\Testing\x64\XenDesktop Setup\MetaInstallerCore.dll
12:05:58.9597 $ERR$ : XenDesktopSetup:The follow command line arguments were specified: '/NOSPLASHSCREEN /XENDESKTOP '
12:05:58.9627 $ERR$ : XenDesktopSetup:Error whilst parsing arguments: System.NullReferenceException: Object reference not set to an instance of an object.
   at Citrix.MetaInstaller.ArgumentParser..ctor(String[] args, ICollection`1 availableGroups)
   at Citrix.MetaInstaller.Server.MetaInstallerServerApplication.ParseArguments(String[] args)
   at Citrix.MetaInstaller.MetaInstallerApplication.Run(String[] args)
12:05:58.9627       : XenDesktopSetup:Current User Preferences follows state: invalid-cmdline
12:05:58.9687       : XenDesktopSetup:ShowUI = False
NoReboot = False
NoPrerequisites = False
UIMode = Normal
LogPath = 
VerboseLog = False
WorkingDirectory = C:\Users\gklp76a\AppData\Local\Temp\rbt_fed69622-52aa-420e-b0ed-38e2dfb8be4f
InstallDirectory = C:\Program Files\Citrix
PreselectedComponents = 
CDRoot = 
InstallationResuming = False
EnableFlashSecurity = False
EnableProGraphics = False
ChangeFirewall = False
ConfigureUdpPorts = False
ConfigureRemoteAssistance = False
InstallRemoteAssistance = True
OptimizeVirtualMachine = False
IsVirtualMachine = False
IsVMWareVirtualMachine = False
XenAppServerLocation = 
FarmGuid = 
ControllerNames = 
WcfPort = 
NoCitrixWDDM = False
CitrixWddmOnHyperV = False
EnablePersonalVDisk = False
DoNotEnableDesktopExperience = False
MasterImage = False
User overriden virtual machine False
NoResume = False
AllowClientHostedAppsUrl (LAA)False


12:05:58.9697       : XenDesktopSetup:MetaInstaller terminating
12:05:58.9697       : XenDesktopSetup:InstallationManager instantiated
12:05:58.9697       : XenDesktopSetup:InstallationManager instantiated
12:05:58.9697       : XenDesktopSetup:InstallationManager instantiated
12:05:58.9717       : XenDesktopSetup:Component 'Microsoft Visual x64 C++ 2008 Runtime' and dependencies instantiated.
12:05:58.9717       : XenDesktopSetup:Component 'Printing Server Role' and dependencies instantiated.
12:05:58.9727       : XenDesktopSetup:Component 'Citrix Universal Print Server' and dependencies instantiated.
12:05:58.9797       : XenDesktopSetup:Product with upgrade code {C6B77583-0ED3-4E64-B9EF-19AFB65A5CEE} is not installed.
12:05:58.9817       : XenDesktopSetup:InstallationManager instantiated
12:05:58.9817       : XenDesktopSetup:InstallationManager instantiated
12:05:58.9817       : XenDesktopSetup:InstallationManager instantiated
12:05:58.9817       : XenDesktopSetup:Component 'Microsoft Visual x64 C++ 2008 Runtime' and dependencies instantiated.
12:05:58.9817       : XenDesktopSetup:Component 'Printing Server Role' and dependencies instantiated.
12:05:58.9817       : XenDesktopSetup:Component 'Citrix Universal Print Server' and dependencies instantiated.
12:05:58.9817       : XenDesktopSetup:Product with upgrade code {C6B77583-0ED3-4E64-B9EF-19AFB65A5CEE} is not installed

Searching for information on the product referenced in the last line showed no relevant hits whatsoever. So, as usual in these situations, it was off to Process Monitor to see what was happening.

Process Monitor revealed only more confusing things - the installer process (XenDesktopInstaller.exe) was simply repeatedly creating, querying and closing a 0KB file called c:\ProgramData\Citrix AutoRun Waiting


This again looks very odd, and this process continues until you terminate the installer process, or delete the Citrix AutoRun Waiting file, of which either will bring the installation process to a premature end.

Concentrating on the last line from the log, I wondered if the pre-requisite checker was failing to install one of the required roles or features properly. To this end, I set off into Server Manager and tried to install Remote Desktop Services manually.

Now, imagine my surprise when the role installation failed with an "Access Denied" error!

installation encountered the following errors...
The request to add or remove features on the specified server failed.
Installation of one or more roles, role services, or features failed.
Access is denied. Error: 0x80070005

This is a bit of a "WTF" moment, as we are logged on as a local Administrator. However - the account isn't a domain administrator (third-party consultants like me rarely are!), could this be the problem?

Permissions-wise, aside from the filesystem, the only other pertinent part of the Windows operating system is the Local Security Policy - user rights. Our investigation now led us into the security console - secpol.msc

Now, everything looks normal, apart from one entry - the user right for "Manage auditing and security log" has been changed via Group Policy.


So local Administrators have had this right removed from them - could this be the cause of all our issues?

Indeed it is - restoring the "Manage auditing and security log" user right now allows XenDesktop setup to proceed and complete successfully!

Incidentally, if you can't get this changed on a domain level, using the old ntrights.exe from the Windows Server 2003 Resource Kit will allow you to add the privilege by using the command

ntrights +r SeSecurityPrivilege -u username

Sneaky! Anyway, you can see that I've finally managed to successfully complete my XenDesktop install - about time!


Summary

So, lessons learned from this are

1.  Try not to customize your user rights too heavily from the defaults. In the absence of domain authentication, removing user rights from local Administrators can invoke the law of unintended consequences (I once saw a server that could not be shut down because of custom user rights)

2.  Be aware that installers can fail in this situation, even if the user right appears to have no real relevance to installing software. SQL Server setup will do a pre-requisite check for this user right, which means that this behaviour has probably been observed previously.

3.  Process Monitor and log files are your friends (admittedly not so helpful in this situation, but they certainly pointed me in the right direction)
↧
↧

AppSense Insight - understanding your EUC environment

March 20, 2015, 3:47 am
$
0
0
When I was awoken at 6.45 this morning by the sounds of my children hunting for their Avengers: Age of Ultron cards, I noticed a Tweet from @stealthpuppy regarding a "new EUC tool from AppSense". Given that I was barely conscious at the time, I elected to flag the Tweet and investigate it later, especially given the Avengers-related emergency that was in progress.

Fast forward a few hours, and a quick peruse of the AppSense website did indeed reveal a new piece of software called AppSense Insight (although every time I say the name, I think of the Project Insight helicarriers from Captain America - the Winter Soldier, which were intended for quite a different purpose). What's this all about then?

Analysis of applications and the user environment is a hot topic for me at the moment, given that I am doing a presentation on this at the Citrix User Group in Newcastle on April 2nd (sign up! The north-east is a lovely place!) and also an extended version at BriForum in May. With only two weeks before I dust the presentation off, I found it rather timely that this had come along.



AppSense have "soft launched" this rather than pushing it out with much fanfare. Insight doesn't appear to be specifically focused on application discovery and desktop environment, but aspects of these things are rolled in with other KPIs such as logon performance, profile size, installed apps, user rights, operating system versions, etc.

I like the idea of this. The whole driver for my "application analysis" presentation came from the problem that IT departments struggle to understand just what is present in their user environment any more. The reasons for this are many - acquisitions, decentralized management environments, user development, SaaS apps, etc. It's true that the IT user landscape is changing, and these changes often mean that the IT department, who are charged with management of this landscape, don't have any visibility of the key areas any more. Insight appears to be concentrating on a broad EUC worldview of this landscape, and if it can deliver on the areas it has claimed, then it will definitely be an interesting product to have in the arsenal. Insight also has a data aspect to it, allowing you to see where users are storing their data. This is another feature that may help out, possibly with regard to compliance or DLP.

Insight is agent-based - I wouldn't expect any product offering a deep view into endpoints not to utilize an agent, to be fair - and as far as I can tell is only currently aimed at Windows endpoints (judging by the availability of Windows agents only). I'd imagine the idea is to feed the Insight analysis into putting together a use case for DesktopNow, so not sure whether any other OS agents will come along until the relevant endpoint software is available for DesktopNow also. It's a standalone product currently, though, so you could probably use it for analysis that wasn't specifically geared towards implementing other AppSense solutions.

Currently the Linux-based appliance is only available for Hyper-V and ESX (no XenServer?), and you can download and install it from MyAppSense. In common with DataNow, you simply attach to it via a web console once it has been configured. The future roadmap seems to indicate that the goal is to provide deep business intelligence from this product - if it can deliver, it will be very interesting indeed.

I'm just kicking the tyres on Insight right now, so expect some follow-up articles soon to see how we can use it to validate the KPIs in our environments (I must confess to being especially interested in logon analysis, and see how this measures up to other tools that do this like UberAgent). It certainly looks like an intriguing addition to the AppSense product set.
↧

QuickPost - how to stop user folders showing as "My Documents" for support staff with AppSense Environment Manager

March 24, 2015, 8:35 am
$
0
0
If you redirect your users' My Documents folders to a network share where each user maps to a subfolder of a root directory (e.g. all users redirect to \\SERVER\SHARE\%username% for the My Documents location), you may find some odd issues plaguing your support staff. When the admins of your system browse to \\SERVER\SHARE and look at the list of user folders, they may simply see a huge list of "My Documents" folders.




This behaviour is by design from Microsoft, which turns the folder \\SERVER\SHARE\%username% into a "My Documents" virtual folder by reading the entry LocalizedResourceName from the desktop.ini file which is placed in the directory. Resulting in chaos for any admins browsing the parent directory, as they struggle to identify the real names of the directories below.

Microsoft offer a few workarounds at https://support.microsoft.com/en-us/kb/947222, but Method 1 is a PITA because you may have already configured thousands of folders in this way, and Method 2 is quite simply a non-starter if you want your admin staff to actually have access to user's data files for troubleshooting purposes. If you were to use Method 2 and just use Explorer to grant yourself access to certain folders as the need arose, you would eventually end up with a bunch of My Documents folders anyway, and the way Explorer handles this permissions change is a mess anyway, simply resulting in complete ACL chaos down the line (see Helge Klein's anti-Explorer article for more examples of how useless it really is). Method 3 - changing the permissions on the underlying desktop.ini file so that your administrative group can't read it - is probably the best bet, so let's quickly use AppSense DesktopNow to remove the permissions from this file and stop this annoying occurrence.

Of course, this method is applicable to a wide range of products and technologies, not just AppSense, but being an AppSense bigot (and occasionally referred to by said moniker at conferences and user groups!), it just made sense :-)

We will run this in the User | Logon | Pre-Desktop trigger (or just User | Logon if you're pre-EM 8 FR 5).

What we need to do is uncheck the inheritance and then strip the permissions from the groups. Normally, in a user home drive, only the user themselves and the BUILTIN\Administrators group (and maybe occasionally the SYSTEM account) have permissions to the files, so you just need to remove the permissions from BUILTIN\Administrators. If you've got something funky (well, downright crazy, really) like the Users group sitting on the ACL with Read access, you'd need to remove that too.

Obviously when a user's My Documents is redirected to this area for the first time the desktop.ini file will be created, so it makes sense to do this after the Folder Redirection has occurred.

The commands we need to put together are shown below, naturally replacing \\SERVER\SHARE with the relevant UNC path for your environment.



Which would leave the whole node looking like this


So, this is a very simple problem that many may have come across before and resolved, but just in case you didn't, this should serve as a quick reminder of how to get past it.
↧
Search

BriForum London 2015 - a virgin's review

May 21, 2015, 5:40 pm
$
0
0
This week I attended my first ever BriForum in London. Being mindful of the expense involved, I actually opted to submit a session to try and get around the problem of forking out cold hard cash to attend. I was suitably surprised when my session was actually accepted, cueing weeks of nervousness as I watched previous sessions and wondered whether a) my PowerPoint skills were actually up to scratch, and b) if I actually had anything interesting to say.



My good self trying to talk app analysis tools

For the uninitiated, BriForum is the independent virtualization conference that was the brainchild of the founder over at BrianMadden.com, Brian Madden (rather obviously), who is ably supported by fellow bloggers Gabe Knuth and Jack Madden. It’s been going for a long time now and in the absence of a European Synergy event, has almost become the conference of choice for European IT pros looking to get technical insight and future roadmaps around the whole virtualization arena. But it’s also independent (despite still having a strong Citrix taste around the whole event), which in my book, is always a good thing. Vendor influence can cast a slight shadow on the value of conferences, so having something that is purportedly vendor-agnostic is always good when it comes to selecting those that you’d like to attend.

Despite there being many parts of the United Kingdom besides London (a common dig you will find me making), BriForum was held right in the heart of the nation’s capital, and I did find it quite an interesting and useful experience. Firstly, it’s always quite fascinating to actually bring your “virtual” world into the real one. There are many people I bumped into who I had only actually previously interacted with online and it was intriguing to actually make their acquaintance. Secondly, I found there to be a great level of technical content across a fairly broad spectrum of attendee experience, deeply-focused sessions mixing quite readily with those that took more of a “twenty thousand feet” view of the whole virtualization area. Even in subjects where I felt I already knew quite a lot about the topic at hand, there was always something interesting to take away, and at the end of the conference I had lots of ideas for new articles and new ways of solving problems that I’m hoping to write up very soon (having now been freed from the pressure of worrying myself stupid about how my session was going to be received!)

I did manage to reap the benefit of being one of the first sessions to be delivered and despite being slightly alarmed that I actually appeared to have a decent number of attendees, I almost perversely enjoyed the challenge of getting it across. Spotting guys like Tim Mangan in the crowd (whose app virtualization articles I’ve been reading for a very long time!) almost took me to a panic-attack-like state of trepidation, but once I got into the flow of things the pressure eased and I’m almost at the stage where I’m thinking I might actually like to try and do it again. In fact, I’d go so far as to recommend to anyone that they give it a go – as long as they don’t end up like poor Jarian Gibson, who someone apparently attempted to poison at the speaker dinner the previous night :-)

There were a sizeable number of interesting characters to meet and vendors to trade opinions with, which added up to what was all-in-all a very good few days. I’d have to give honourable mentions to Dan Bolton for his unique presentation style, Dane Young for some high-quality heckling, Dan Allen for being generally boisterous and offering his opinions on PVD, Tim Mangan and Ian Parker for being very polite and attentive despite the fact they seemed to struggle with my north-eastern accent, Jim Moyle for dispelling the myth of the two-fingered salute, Kevin Goodman for paying for a whole host of beers and Andy Wood for not reacting badly to my taking photos of him while he was asleep (on the train) and posting them on Twitter. All japes aside, I found it very useful and I came away after the exchange of ideas with many people feeling suitably inspired to try new approaches and methods in my day-to-day consultancy, which is a very good thing.

There were some interesting vendors attending too – outside of the usual circles of vendors like Citrix, VMware, Atlantis, AppSense et al, there were some of the newer, more disruptive ones such as FSLogix and Cloudhouse peddling their wares, which again made for some interesting conversations.

What were the main points I could take away from the conference as a whole? I feel the consensus seems to be that layering, such as done by AppVolumes and UniDesk, is something we’re still waiting to see deliver on the promise that it has made over the last couple of years. And the fact that IT departments the world over still seem to be making the same mistakes that they always have. And there still isn’t any clear sign that an “end-to-end” solution such as those provided by Citrix and VMware is ready to take over the EUC market any time soon – despite these companies being involved in what now amounts to an all-out feature war, there isn’t yet a heavy push from the customer end towards adopting these technology stacks en masse.

But the biggest focus I found was that people are still having to be told that user experience is king. No matter what the metrics, the goals, the success criteria, the focus is still absolutely on user experience as the primary driver. And I think that’s good. We’re finally reaching an era where IT is service-oriented, where they’re looking to enable their users, to serve the business rather than serve the inflation of their own departmental self-importance.

So I’m hoping that all those who attended BriForum 2015 in London found it as useful as I did. Hopefully I might even have contributed something to this through my own session! But also let’s not forget it shouldn’t all be deadly serious and technically-focused – it should be about having a bit of fun. I’m sure Will Southern from Noble Foods did, managing somehow to win the “Geek-Out” quiz despite the fact that one of his rivals answered the hardest questions and finished last.

The prize for the Geek Out champion - let's see him defend his title in Denver
All in all, a very good few days. If you’ve never been to a BriForum before, I’d definitely recommend that you do give it a go at some point - the sooner the better.

And with any luck, normal blogging service should be resumed from hereon in, now that I’ve broken my conference-presenting duck and relieved myself from all the associated pressure!
↧

QuickPost - Debugging AppSense Environment Manager in a post-EM 8 FR 6 world

June 2, 2015, 4:58 am
$
0
0
For a long time now, AppSense administrators have had to become familiar with the EMClientDebug tool when trying to capture errors, and feeding this into the EM Log Parser for analysis. The process always felt a bit disjointed to me, particularly as the Log Parser tool had to be downloaded, and also down to the odd issue that some of the log files wouldn't load at all. It's a part of the AppSense interface that has been ripe for an overhaul, and with the advent of Environment Manager 8 FR 6, it's finally received it.

The debugging tools (now called ClientLoggingSetup under the hood) still ship as part of the standard Environment Manager Tools MSI (as opposed to the Environment Manager Policy Tools, which were new in EM 8 FR 5, if I remember correctly). So firstly, you will need to install the tools onto an endpoint (although this doesn't necessarily need to be the endpoint you're actually going to debug, just an endpoint with the same processor architecture). Most of the time, I simply install them onto an AppSense server.



You can select just the ones you require as above, or do what I do and simply install the whole suite for posterity.

Now that the tools are installed on the server, assuming your endpoints are also x64 (because no-one still has x86 application servers, do they?), you can simply browse to the system drive of the server and run the debugging tool directly. Go across to the following path (where ServerName matches your server with the tools installed)...

\\ServerName\c$\Program Files\AppSense\Environment Manager\Tools

...and simply run the ClientLoggingSetup executable (if you're not an administrator on the endpoint, you'll need to Shift+right-click and choose Run As Different User)


The interface you're presented with will seem somewhat familiar, if you're used to the old EMClientDebugSetup tool.


Clicking on the "big button" will turn the logging on as you'd expect...


...but with some major differences. We're now logging out to the familiar ETL trace file format which allows us to manipulate the logs in many different log collection tools, and we can set a whole host of customizable options, from file and buffer sizes to log types to granular trace controls. You can choose to log out as much or as little as necessary, even concentrating on lockdown or managed apps if you prefer. Unless you want to drown in logging, though, I'd advise keeping the detail to Trace unless advised otherwise by support.

You'll also notice that the default directory is now c:\Logs, instead of having to always supply a logfile folder. Clicking on OK commits the settings and starts the logging process, so we will do this with the default settings active and apply a configuration that we know will generate some errors when the user logs in (some errant drive mappings should do the trick).

Once we've logged in with our erroneous configuration, it makes sense to stop the trace log. Browse back to the network path where the EM Tools are installed and run the executable again.


Click the big button and then click on OK to commit the changes and stop the debug trace.


Now, we should see a log file in the c:\Logs folder.


Unlike the old-style debug tool, though, you can't just crack ETL files open in a text editor. We need to go back to the folder which held the EM Tools install, and this time open up the executable called EmMon.exe (EM Monitor). This will also run remotely despite not being installed, handily.


We can open up the log file by clicking on the yellow icon next to the legend saying "Open log file". Browse to the file in c:\Logs and select it, after which you should see the interface loading the file.


You can pull out the pertinent pieces of the logfile by clicking on one of the ready-made report links, but the two you will probably be most concerned with in day-to-day admin are "Search for failed actions and conditions" and "Search for any failures". Let's give one of these a try and see what we see...


Straight away we can see the user listed and the failure counts. We can expand the failure counts to see more details...


...and then highlight each one to see exactly what went wrong.


In this case, our printer mapping failed because of an invalid printer name. Nice and easy! Also, in the last two images, note the timeout for the second error (an invalid drive mapping) - more than 10 seconds! Not really something we want to see a lot of in our configs, so we can see the value.

So, the debug process hasn't really changed that much from how we do it - but we now have more power, more detail, a standard file format, no service restart required, built-in reporting functions, and full event log integration. Previously you might find yourself digging through masses of events, struggling to set up filters, and generally getting confused, but everything is now much more streamlined and to-the-point. This is a long overdue revamp for the debug utility to go along with all of the other new features in EM 8 FR 6 - new features which hopefully will be among the subjects I shall be covering very soon as I try to push out at least two new blog articles a week!
↧
↧

FSLogix first look #1 - managing legacy or multiple Java versions, the EASY way!

June 2, 2015, 11:14 am
$
0
0
There's been a lot of buzz recently about FSLogix, who are a company making a few disruptive waves in the virtualization world with their core products. The beauty I see in FSLogix is that it is very much a simple product - almost reverse app layering, to coin a phrase. It delivers user entitlements to applications based around using a filesystem driver to "reveal" the applications as necessary, rather than delivering them on-demand through app virtualization or layering tech such as App-V, AppVolumes, and the like. In a world where complex solutions are often king, I find FSLogix is a breath of fresh air for businesses that don't have the budget, the skills or the resources to invest in "Rolls-Royce" infrastructure. This is not to say complex solutions don't have their place - very, very far from it! - but they're not the only way to get things done. And FSLogix's products are not just aimed at SMEs either - simplicity can be just as elegant at scale.

But rather than dive straight into FSLogix's core product, FSLogix Apps, for this first instalment we will take a look at a part of their portfolio that solves a common operational problem just about everyone can identify with - the management of legacy Java apps and multiple Java versions. Don't you all just hate Java? The world would be a better place without it. I can recall many, many instances where I've had to shoehorn legacy Java versions into application silos, App-V packages and base images. In fact, for a long time I've been keen to try and manage it through AppSense Application Manager, and I'm pretty sure it can be done in this way (I am getting around to testing this - I promise!) However, if you're not an AppSense customer and want to manage Java versions (or you just don't have the patience to wait for someone like me to test it), FSLogix is a wonderfully simple way of achieving Java management heaven.

Let's take a Windows 7 image and install a couple of Java versions onto it firstly.


In this state, our machine has a later Java version installed (8.31) but is still vulnerable to the security exploits available through the legacy version on the machine (7.71). The idea is that FSLogix will "cloak" (i.e. hide from the operating system) the legacy version unless a program or URL is visited that specifically requires it, massively limiting the exposure to drive-by attacks. So without further ado, let's install FSLogix Apps and the FSLogix Java Rule Editor.


Now that they're installed, let's pick some Java test sites that we can use to demonstrate what happens. We are going to use the standard "Verify Java" detection page from java.com in the first instance, because that detects all versions of Java on the machine and will show us how this software hides the legacy versions until they're called.

For the old version, we will use http://www.javatester.org/version.html, so that we can see it uses the older version and can't detect the newer one - showing that good 'ol FSLogix is doing exactly what it says on the tin.

Firing up the FSLogix Java Rules Editor allows us to select the URL (or process, for that matter) and associate a Java version with it. The interface in this version is very simple, to say the least, but I'm a fan of substance over style any day of the week. Interfaces improve easily...poor functionality is harder to make better.



Next, we will add the second URL in that we mentioned above, and associate the old Java version.



Finally, we need to deploy this - in so much as there is any deployment to speak of. You save the rules, then generate some deployment files, and then copy them into %PROGRAMFILES%\FSLogix\Apps\Rules, from where they are compiled and enabled. Once they're in there, the service automatically brings them into usage - no mess, no fuss! This sort of deployment could easily be automated from a central location or locations using Group Policy Preferences, AppSense, RES, many other bits of software, even a bit of PowerShell or batch. That's part of the appeal - it sits easily in with other enterprise deployment tools, or can easily be handled by an admin.



So, let's see it in action! Firstly, let's go to the Java.com version tester. Anyone familiar with this knows it detects all versions installed on the desktop. So what happens when we go here?



That looks very good...it is only detecting the 8.31 version, and even though it's recommending the newest version, it doesn't know about 7.71 at all. That's because FSLogix has hidden it from the OS completely. Don't believe me? Let's empty the Compiled Rules folder in the FSLogix program data (essentially resetting it to default settings), and then revisit the same page...



Cool! We know now that FSLogix was hiding the legacy, vulnerable Java version, and now we've turned it off, it's there for all to see and exploit.

So, re-enabling our FSLogix rules, let's now visit the javatester.org URL, where the old version is allowed out of the woodwork...



...and then let's turn FSLogix off again, just to see what this page shows normally when there are two versions installed...



...and it's exactly as expected. Now that FSLogix isn't hiding the newer version to allow compatibility, the page has gone back to the later version. Hiding the newer version allows sites and applications that are incompatible with newer versions to continue operating without incurring a massive security risk to your org. Pretty cool stuff!

The Java bit is almost an aside to what FSLogix Apps really does - really it is concerned with application delivery and management from a single image with apps installed. But we will have more on that in the second and third parts. They also have features that can now deliver apps from the network and handle user profile management - but we will come to that in future articles.

The reason I started with the Java version control and management is that this is a real-world problem that just about everyone has come across and has pain with. Think of all the effort and infrastructure that goes into maintaining legacy Java-based apps that the vendors can't or won't update to the latest versions - and then replace it with a simple solution like this. I think it is very interesting.

You do have to fiddle with a lot of Java settings sometimes to get things to work (deployment.config files, security lists, etc.), but it's a hell of a lot better than the alternatives in my opinion. There's also the fact that the interface is still very simplistic, but that can easily be improved. All in all, FSLogix has some interesting features that make it something we should all be aware of, and the Java management is just the tip of the iceberg - more to come!

If you've got any questions about FSLogix you might want to fire at me, then by all means leave a comment or contact me on the email address on the About Me page.
↧

Setting AppSense Personalization Server status based around a user-defined choice...and making your computer talk....and standing up multiple instances of Personalization Server

June 7, 2015, 12:25 pm
$
0
0
This is going to be another of those absurdly-titled long posts (like this one), where I go around the houses attacking a problem before arriving at a completely different decision. But hey! I enjoy the journey and the learning. Where are we off to this time?

I've been doing some work in higher education recently and the requirement we started with was to split a single desktop image into two distinct environments, Students and Staff. The Student desktop was intended to be limited in functionality for most applications (the idea being that "teaching" apps would always be in a pristine, non-customized state), whereas the Staff desktop would be almost a "regular" environment with fully customized apps and workspace. I've been down this route before, but the difference this time was that the "Staff" desktop would offer them a choice between logging in to their normal work environment and logging in to the "Student" one. Naturally I first suggested simply giving them a "Student" user account in addition to their "Staff" one and subdividing the environment around the userid, but they wanted access to these two distinct areas provided to a single user account for each person.

So we had the following unusual requirements:-
  1. Configure some way of offering users a "choice" of desktop after they log in
  2. Adding an audio element to the "desktop choice" to remind users that it needed to be interacted with
  3. Disable Personalization for the Student desktop, and enable it for the Staff desktop

Requirement #3 is the most interesting, mainly because you can't set Personalization Server membership rules based around anything other than user or device specifics, so that looks fairly challenging. But anyway, let's get on with the journey.

Setting the "desktop choice"

I'm no developer, so this was always going to be rudimentary. What I had in mind was calling out to a script at the start of the Desktop Created trigger and setting a Registry value based on the user's input, which could then be used as a Condition in the child nodes to set the look and feel of the environment. The key part was stopping the execution of the entire logon in order for the choice to be set, which we did by nesting a child action underneath the script and making all other nodes dependent on (children of) this one.

We used PowerShell to ask the user for input


Naturally, we unset the "non-interactive" option to allow the PowerShell to be seen by the user


and then we can use the Registry value set by the user as a Reusable Condition to ascertain which environment was selected. Note that the Registry key you're writing to actually needs to exist or the script will fail trying to write the value, so either make sure the key is in the base profile or do a bit of If Condition magic to make sure it exists before executing the scripted Action.




So, when the user logs on, they are presented with this choice (see image below). If they select something other than the two choices, they are asked to choose again - if they escape the window or close it, they are sent to the default (Student) environment. Cool!



So that's the first requirement fulfilled - although not particularly pretty (the guys I am working with actually tidied this up using WinBatch and gave me a nice interface which I could call from a VBScript Action). Now, what's next?

Audio reminder of logon choice

Now this is a bit more challenging - but luckily I follow Jeffery Hicks on Twitter and I remember him posting a bit of PowerShell once that I could possibly use to achieve this without too much fuss. Thanks Jeff (and your PowerShell book is very good too!)

What we are going to do is simply insert some more PowerShell into the bit we've already done so that the choice is spoken to the user as well as presented in a console window.

Obviously the success of this is dependent on the user actually having a sound card and the sound audible - you can do cool things with the PowerShell SpeechSynthesizer object such as increase the volume and whatnot, but that's a bit out of scope for this article, although there are some good articles out there on the Interubes about the various properties available. For our purposes, we'll assume anyone that the audio reminder is applicable to will have sound configured correctly.

I was also running this on Windows 8.1 so I get the choice of four different voices - Microsoft David (American), Microsoft Zira (American), Microsoft Hazel (English) and Microsoft Heera (Indian). On Windows XP you used to get the well-liked Microsoft Sam, but in Windows 7 Sam was killed off and replaced by the robotic and despised Microsoft Anna. If you're doing this on 7 you can download extra voices here - but you will need to change the script below for your operating system voices, should you want to do this bit.

If you want to see the voices you've got installed on your system, run these commands in a PowerShell console

Add-Type -AssemblyName System.speech
$speak = New-Object System.Speech.Synthesis.Synthesizer
$speak.GetInstalledVoices().VoiceInfo

Anyways, the modified AppSense Action to get the speaking component added looks like this



So now, when the "logon choice" box runs, we get the command spoken as well. Probably not very useful in most environments to be honest, but it was asked for in this example - and frankly it's quite a cool demonstration of stuff you can do with PowerShell :-)

Enable or disable Personalization based around the Registry value we set

This is the tricky bit. For the Student desktop, Personalization is to be more or less disabled, whereas it was to be fully enabled for the Staff environment. I'm sure you're all very aware that Personalization can only be set on user or device specifics, and the Conditions for membership of Personalization Groups don't yet encompass the full spectrum of EM Conditions available in Policy. (Please please please, AppSense, add this in as a feature in future - it would be really useful!)

So the first thing I thought of was to set the Personalization Server ADMX files based around the Registry key, pointing them to a "dummy" Personalization Server if the Student value was set and the real one if the Staff value was set. Sounds good...

...apart from it doesn't seem to work in testing. If you have an ADMX file that points only to a fake Personalization Server, it seems to go running back to the one stipulated in the actual EM config file.

Next I tried to think of some way of "killing" Personalization. There are some Registry values that will stop Personalization from happening, namely

HKLM\Software\AppSense\Environment Manager
RegistryVirtualization DWORD 0
FileVirtualization DWORD 0

although you have to restart the Environment Manager/User Virtualization service afterwards to make this work. This sounded doable, though...



...but as you may have guessed, when the service stops, the policy stops, so the service never restarts or sits in a "stopping" state. What can we think of next?

Continuing on my thoughts around enabling Personalization in the configuration but then making it impossible to happen, I wondered if I could use some trickery with the hosts file to point the user to a fake server? Again, this sounded like it had potential...so we set up a hosts file with an incorrect entry for the AppSense Personalization Server and put it in a network share



and then set our AppSense Actions to copy it in if the Student desktop was selected, and then flush the DNS cache



This actually worked quite well, as long as we remembered to restore the original hosts file when the Staff desktop was selected. However, you couldn't do this at logoff, as the logoff actions run before Personalization and Windows Personalization Groups would then synchronize when you didn't want them to. There was also the issue that as we were testing with a combined Management/Personalization server, when the Student environment was selected new configurations couldn't be deployed or event data uploaded, as the endpoint simply couldn't contact the Management Server. So it was effective, but it felt like it was a bit of a botch job and probably could cause problems in future.

Of course, then I noticed the obvious answer sitting in front of me. Why bother with all of this - why not just have two Personalization databases and instances, one for Staff, one for Students, and never the twain shall meet? This solution seemed even more suitable when the client announced that the Students might actually be allowed to Personalize certain applications such as email and intranet. There was no reason that Staff would ever need their Personalization in the Student environment - access to it was only ever intended to be used for testing, training and troubleshooting. So why not just have two completely isolated environments?

Setting up multiple Personalization Server instances

Luckily, in EM 8 FR 5 AppSense provided the capability to host up to sixteen instances on each Personalization Server, otherwise this would have necessitated a whole new server to support it.

On your Personalization Server, re-run the AppSense DesktopNow setup and choose Modify. On the Product Selection screen, expand Environment Manager and you will see Add new Personalization Server instance



Once this is done, you will need to configure the instance to point to a new database and set up a new website in IIS to support it. In IIS Manager, I simply created a new website called PersonalizationServer2 running on port 81



and then connect to this site in the Personalization Server Configuration Tool for the new instance, before creating a new database with the required name



I can now test the connection by browsing to http://servername:81/PersonalizationServer/status.aspx and see if it is all working



And finally, I can configure the AppSense ADMX files to point to the required new Personalization Server instance when the Student environment is selected...





...which will then allow me to disable all but a small part of the Personalization for users in the Student environment, and leave it fully enabled for users in the Staff environment. We got there in the end!

Summary

Everywhere you go you will get unusual requirements...some of which you may possibly never see again. However, it's an enjoyable learning experience as you try to meet these requirements, and it certainly lets you find out the power and/or limitations of the software you're working with.

I'd really like to see the full scope of EM Conditions extended into the Personalization Server membership rules, however. This would make requirements like this a lot easier in future. But in the end we got it working in a way satisfactory to the customer - which is the main thing!
↧

Improving Citrix XenApp session performance by blocking ads in Internet Explorer

June 17, 2015, 2:32 am
$
0
0
I've done a lot of talking recently and in most of it, I've been trying to impress upon people the importance of that subjective and almost intangible quality called user experience. But one of the more tangible aspects of user experience is undoubtedly performance, and particularly on shared session systems such as Citrix's XenApp or XenDesktop platforms, it becomes absolutely critical.

At the Citrix User Group in Newcastle recently one of the presenters was Thomas Poppelgaard, a member of the CTP program and an affable guy who I had a few beers with on the first night of BriForum. One of the very interesting takeaways from his session was the fact that he reported most GPU usage was down to browsers, rather than the usual suspects such as AutoCAD and other graphics-intensive applications. His summing up of this issue was quite simply "deploy an ad blocker to see improved performance", so I took his advice on board and decided to see how difficult it was to deploy an ad-blocking piece of software to the machines in my lab.

Lots of ads these days not only are animated (hogging performance), but they also connect up to third-party sites that could potentially be compromised, so they're part of the system attack surface also. So not only are we looking to improve performance for our users (and in heavily-loaded XenApp environments, every CPU cycle and byte of memory counts!), but we're also looking to improve system security - a good double-edged approach if ever there was one.

The server I worked on was a Server 2012 R2 build, fully patched, naturally with Internet Explorer 11 as the browser, running XenApp 7.6. I also tested this against a Windows 7 machine to see if it was nice and portable. I (surprisingly) used AppSense DesktopNow to deploy the required settings, but I've also demonstrated how they can be done through standard tools like Group Policy. The server we're using for the first round of testing also has a bunch of GPOs applied to it, mainly regular stuff, such as loopback processing, removal of roaming profiles, RDP enablement, and enabling new IE add-ons.

The website I chose to test on was my old faithful I.T. newsstand The Register, which I have noticed puts out a lot of banner ads, often involving animation.

What to use?

My first thought was the old trusty ad-blocking plugin AdBlock Plus, as I have used this in Firefox for many years with great success. However, this not only raises issues of deployment and configuration in an automated fashion, it also requires an installer, which was difficult (but not impossible!) to find. Add to this the fact that ABP is controlled by specific .json files rather than Registry keys, and it seemed like it would quite quickly become difficult to manage in an enterprise environment.

So it was quite surprising when I discovered that ad-blocking (or content filtering, to give it the correct term) had been part of Internet Explorer since IE9 in the form of Tracking Protection. Originally I suspected that Tracking Protection simply prevented websites from offloading your data to third-party websites (which is probably why I ignored it), but I was pleasantly surprised to find it did allow you to block content using an add-on called a Tracking Protection List (TPL). You can use the same list as Ad-Block Plus (the EasyList, which is the one we'll use), so if you are using Firefox or Chrome with ABP you can configure the same level of protection for Internet Explorer using the built-in tools.

Here's The Register in its default ad-ridden glory (with the ads highlighted, just in case you didn't notice them)


and here it is with Tracking Protection enabled (or ABP - either way you'd get the same result)


Obviously if you're not using Internet Explorer as your browser you'd have to resort to something like ABP, but in my experience a lot of enterprises are still tied to Microsoft's default browser, so I've left other browsers outside of the scope of this article.

So Tracking Protection it is - how do we configure this for our XenApp users?

Enabling Tracking Protection

As with most things Microsoft these days, it isn't that easy. Microsoft get a bad press on this blog...but they deserve it. I'm not a Microsoft hater - I think a lot of their products are excellent - but they really don't make things easy for users and administrators sometimes.

For starters, there was a GPO to configure Tracking Protection in IE9 - but this was then removed in IE10. You could also previously configure Add-Ons through Group Policy Preferences - but this functionality also appears to have been deprecated (see image)



Resorting to tried-and-tested techniques, what we are going to do is log on to the server through a XenApp published desktop, enable Tracking Protection with the EasyList, and then export out the relevant files and Registry values by using Process Monitor to view them. You've never had a truly satisfying day at work unless you've broken out a bit of Process Monitor :-)

Log on, fire up IE11, and then click on the Tools icon in the top right (the "gear" icon that for some reason brings back shades of Resident Evil to me). Select Manage Add-Ons from the resultant menu, and click on Tracking Protection in the list of Add-On Types.

Then click on Get a Tracking Protection List Online, and from the web page that appears, select one (EasyList Standard at the top being the one AdBlock Plus uses, and the one I'd recommend). Click on Add List from the dialog box, and you're done (although you may have to close the Manage Add-ons dialog and reopen it before you see it added in there).



So now we just need to see what Process Monitor shows us...

..and we get a bunch of Registry values and filesystem entries that look kind of promising. First we find is

HKCU\Software\Microsoft\Internet Explorer\Safety\PrivacIE\Lists\{GUID}

which looks like a good key, especially considering that it contains an entry pointing to the exact same filesystem entry that Process Monitor shows us, which is

%LOCALAPPDATA%\Microsoft\Internet Explorer\Tracking Protection

which contains a .tpl file, and given that we're dealing with Tracking Protection Lists, seems very interesting!

So what we need to do is

1. Export out the Registry values from the Lists key and import them in when the user logs in

2. Copy out the .tpl file from the profile and copy it in when the user logs in

Hopefully these will automatically enable the TPL and allow us to block content using the EasyList without any user action being required.

Deploying the Registry values and filesystem entries

Now it's a case of pick your poison. Given my history, we will cover doing this through AppSense DesktopNow Environment Manager, and also Group Policy Preferences - but there's probably a multitude of ways to get this done, choose the one that's easiest for your own environment.

Registry entries

Deploying these through AppSense Environment Manager is nice and easy - use the logged-on user we currently have with the settings enabled, and export them out to a file through regedit.exe, before using the Import A Registry File function in Environment Manager


Group Policy Preferences also has a similar function, the Registry Wizard, under User Config | Preferences | Windows Settings | Registry. Use this to browse to the local or remote Registry location and bring in the settings (make sure to select all the values in the key!)


Whichever method you use, make sure you change the data for the Path value from the default (which in our case is this)


C:\Users\jrankin\AppData\Local\Microsoft\Internet Explorer\Tracking Protection\{GUID}.tpl

to the path with the %LOCALAPPDATA% variable


%LOCALAPPDATA%\Microsoft\Internet Explorer\Tracking Protection\{GUID}.tpl

and also make sure that the Type for the Path value is correctly set to be REG_EXPAND_SZ rather than just REG_SZ.

Filesystem entries

Obviously, seeing as though one of the Registry values points to the .tpl file in the %LOCALAPPDATA% path, we need to make sure the file is present when the user needs it.

First make sure we've grabbed the original .tpl file that we created when we configured Tracking Protection and copied it somewhere (network share, or local to the machine).

Using AppSense, we can easily fire up a File Copy Action to handle this



It's also easy enough to do this in Group Policy Preferences using User Config | Preferences | Windows Settings |Files



So now we've got the files and Registry entries in place, we just need to make sure that the user can't mess with the add-ons. Usually I do this with the Group Policy Object "Do not allow users to enable or disable add-ons", deployed through AppSense EM or standard AD Group Policy.



However, an oddity I noted was that this GPO simply disables the entry point in Internet Options (see below)



...whereas the option for Tools | Manage Add-ons is still very much active, even with this GPO in place, not just from the "gear" icon, but also from the Tools menu (which you can reveal by pressing Alt)



This isn't something that can be easily gotten around unless you're using a piece of software like AppSense, which can be used to selectively disable this part of the interface (see image below for an example of the interface with the Lockdown applied). In this case, we've disabled the Manage Add-ons item under the Tools button, and the Manage Add-ons item on the Tools menu. We could even go so far as to disable the Alt-X keystroke (the Tools shortcut key) within iexplore.exe, but with the options disabled this isn't necessary.



If you're not using something like AppSense EM, you will have to face up to the fact that savvy users may be able to get in and change the Tracking Protection settings, but as long as you use something like Group Policy Preferences (preferably in its aggressive "Replace" mode) to overwrite the files and Registry values at every refresh interval, the chances of this being a big issue should be somewhat minimized.

Demonstration

So, we've configured our Tracking Protection, exported out the settings, and delivered them through the method of our choice. Does it work, and more importantly, does it look like it improves system performance?

When I log in to the XenApp server, I can see that the files and Registry values are present, and the EasyList is configured correctly. Excellent! But more importantly, it blocks the ads on The Register (the little "content filter" icon - highlighted in the image below - proves that it is working)



But now let's look at a quick snapshot of system performance with the Tracking Protection enabled and the same website displayed. We grabbed a sample of the VM performance from Task Manager on ten occasions, and the average was about 30-45MB of memory and very low (almost constantly zero) CPU usage (see below)



Now we will disable the Tracking Protection and grab ten quick samples again using the same web page. The average was now in the 65-75MB range for memory, and the CPU usage was a lot less static, jumping from 0 up to 20% (see below).



So that looks very promising indeed - less drain on CPU and memory resources on a per-session basis, which in a XenApp shared session environment should give you a performance boost and/or higher user density, both of which are good things!

Finally, we dropped the configuration onto a Windows 7 machine to see if it was nice and portable (obviously running IE9 or higher, otherwise Tracking Protection would be non-existent), and it did indeed work exactly as it did on the 2012 R2 XenApp server. Sweet!

Summary

So, it indeed looks as if blocking ads, in this day and age, is a good way of getting a performance boost out of your XenApp (or other shared-environment) systems.

There is always the problem that the Tracking Protection list may block some functionality of some internal websites (although all my testing didn't demonstrate this even once, to be fair), so if you do encounter some oddness, you may need to go in and edit the list directly in the .tpl file (which looks less than straightforward, if I'm honest).

And obviously this only applies to IE - if you wanted to extend this to Chrome or Firefox or A.N.Other browser, then you'd have to look at AdBlock Plus or similar plugin. However, as far as I can tell there aren't Registry values or file entries that can control the behaviour of ABP (most pertinently, the functionality that allows users to bypass it), so you may find working with ABP in an enterprise environment slightly more challenging, although certainly very doable.

Anyway, here's hoping that this may be of use to those of you with XenApp environments that are fighting the never-ending battle of trying to make your user's lives easier.

Update

Hans Straat has taken what we've used here and showed how it can also be done using RES Workspace Manager, see http://www.datacrash.net/post/2015/06/18/Disable-adds-with-the-help-of-Res-Workspace-Manager.aspx, nice work Hans! 

Credits

Kudos due to Thomas Poppelgaard for his user group session that made me think of ad-blocking as a way to improve Citrix session performance.
↧
Viewing all 178 articles
Browse latest View live
Search