Windows 7 VDI and 2008 R2 XenApp 6.5 Optimisation settings delivered via AppSense Environment Manager

There are many articles, blogs, best practice guides abounding on the internet that discuss optimisation settings for Windows 7 VDI and Windows 2008 XenApp sessions. It takes significant time to test them all and then develop a method of deploying them to multiple machines within the enterprise.

Here is a compiled list of some of these optimisation settings delivered by an AppSense Environment Mamager Policy.

The settings included are by no ways definitive or a compelte list, however include many of the best practice settings from vendors such as Microsoft, Citrix and AppSense as well as many industry best practices, and settings from the field.

The purpose of the configuration is to reduce the time required in creating one of your own. It does not however eliminate your need to test these all throughly in a test environment before letting them out into the wild and as such come with no warranty.

The Configuration is an AppSense EM Console 8.3 Version

Download the Configuration File: Download the Optimisation Config
Download the Word Document: Download the Word document

AppSense DataNow - Overview 

AppSense have recently released various beta versions of their latest product DataNow, so what is it and what can it do for you and your organisation.

Firstly, what is it?

So AppSense market this using at least two catch phrases, "On premise data solution", and a "Data Broker".

Locating your or your companies data in the cloud comes with risks: security, ownership, leakage etc. DataNow avoids those risks as it does not move any of your data to the cloud but rather enables cloud access to your data. This is where the ubiquity comes from. DataNow provides anywhere, anytime, any device access to your data where it is today, inside your organisations firewalls, protected, backed up and importantly still owned and controlled by you or your organisation.

Your storage guys are happy, your security guys are happy. Nothing has changed directly with your data and the associated storage platforms that support it. Your security guys don't have the massive headache of data no longer on premise. However they must think about data leakage and how it can be prevented and audited.

The second term AppSense are using is a Data Broker. For the last ten years or so we have seen the separation of the layers making up the general Windows stack. We have separated computers from hardware with virtualisation. We have separated applications from computers with application virtualisation. We have also separated the user personality from computers using user virtualisation. But what about data? Essentially isn't everybody's job in IT to provide users with access to their data?

DataNow is separating data from any other layers or dependencies. As a user simply put, I have data, data that I need. I have that data in various locations, I have it on my homedrive and my shared drives provided to me by IT. But I also have data in DropBox, SkyDrive, Sharefile etc. I want all of that data made available to me in one location, and I also want to get access to that data from anywhere independent of a specific computer. Admittedly some of that data with the various cloud providers may be personal but some of it is definitely work related. Here comes the Data Broker moniker. AppSense promote DataNow as being a broker to a users data. As it stands today DataNow brokers users to only one of their data locations, so its still a little bit of a work in progress. Admittedly that location os the the one location where all users locate the vast majority of their data; their AD defined home drive. However they have stated that DataNow will broker requests to a users shared locations, such as a company shared drive(s), plus other external cloud storage providers. As soon as it can broker these requests then yes it will be a true broker. Which is a significant step forward to completing the separation of data from the current dependencies it has.

So what else does DataNow give you?

Well as above it removes the dependency on a Windows machine to get access to your data.
Speaking in massive generalisations most organisations enable data access through a Windows machine. It may be a Windows desktop or laptop on their desk or a virtual desktop be it a VDI or a shared desktop such as XenApp used on premise or remotely. If a user wants access to their data, then they have to first connect to one of these machines. But why? Data is separate form a machine. Why must a user connect to a Windows machine to be on boarded to their data. Should the user not be able to access their data from anywhere, independent of their device. Yes, is I think the answer.

DataNow provides access to that data internally with as little as the DataNow appliance and a browser. Once connected the browser view follows the same pattern as DropBox and all the others for presenting that data. Files can be downloaded, uploaded and deleted just via a browser. In addition there are clients for Windows, MAC's tablets and smartphones that enable synching of the same data in the case of Windows and MAC's and viewing and deleting when installed on tablets and smartphones.

The second thing it gives you is BYOD access to your data. Now again a big generalisation but BYOD really means BYOM: Bring Your Own Mac. I am yet to see many people bringing in their Windows machines into the office. However the reverse is true of the MAC Books. DataNow through its MAC client provides a simple method of giving these users access to the same data as if they were sat on a corporately provided Windows machine. Admittedly there are others ways of doing this. But if you were concerned about enabling Cloud access to your data and just wanted approved BYOD users to have access to their data, then get them to install the MAC client on their Apple, configure it to point to the DataNow Appliance and there you have your HomeDrive synching with a local drive on the MAC, also available offline.

What does it need to get uptake in the enterprise?

It needs to be a true broker, connecting users to all of their sources of data. It also needs to have policy control. Now AppSense are the daddies at policy, it run's through the veins of all of their products specifcally Environment Manager. DataNow needs some level of policy control over how, who and where, data can be accessed downloaded, uploaded etc, and under what conditions. IT requires that it can audit events such as downloads of files to notify security of potential data leakage.

This may come through AppSense's recent acquisition of RapShere but that seems to be tablet/smartphone specific and based around geo-awareness. Hopefully AppSense will get some of this policy capability from their other products ported into DataNow.

It also needs to be flexible in how it integrates into an organisations already complex infrastructure, i.e can it integrate with other authentication, proxy products etc.

Is it worth it? If you want ubiquitous access to your data without shifting it to the cloud. If you want data access on BYOD devices without having to use a MAC as a thin client to connect to a Windows VM to get access to data, then yes.

Next blog will be how to deploy and configure the appliance.

AppSense DesktopNow 8 FR 4, When to layer when to merge?

AppSense have recently released the rebranded Management suite as AppSense Desktop now version 8 Feature release 4.
There are a number of great new features a couple of which are discussed here. They are Configuration Layering and Configuration Merging. So what are they and what are the differences and for that matter similarities or are they mutually exclusive? Some of this will be based on only what your use case is, so feel free to disagree but often times functionality gets used in different ways than the use cases it was specifically designed for.
So let’s start with configuration layering.
Layering is done at the console side, and as the name suggests layers one or more configuration over the other. Why would you layer configs?
Say you have multiple sets of administrators, infrastructure admins for server based config and desktop config, and application admins for the application deployment and config. Each of these teams may well develop, test and deploy their own parts of a production config. This can lead to issues about multi concurrent editing of the one configuration, i.e. who has made what changes to it and where, when is it ready to deploy whose changes are in it etc. etc.
Layering allows those teams to independently develop their own parts of the config and when ready come back and layer it over the base config. Once this combined “layered” config is saved it can be deployed as a normal configuration, saving the meticulous checking of a single config that may have been edited independently by numerous administrators to ensure that actions are not duplicitous or contradictory, or that settings have not be overwritten.
In the below example is a Base configuration which contains settings for Windows 7 and Windows 2008 settings applicable to security, look and feel etc. It has been configured by a desktop admin, and it has no application settings. Then an application administrator has separately been developing an application specific config with some process start actions in relation to two new apps being deployed. We are going to layer the application config over the baseline to create a complete baseline plus application config.
So what about Configuration Merging?
Unlike layering which is done at the console side, merging is all done at the end point. It provides the capability to deploy any kind of configuration, and then to send out a second, third etc. config and have the client as the name suggest merge these together, aggregating the actions within both.
So why would you use this?
Again using the same example as above you may have a baseline configuration, or possibly you already have a complete configuration with  all of your application process start actions. But now you have a new application being deployed or updated and you need some new process start actions deployed quickly. If your're a large enterprise you are likely to have to go through some rigorous change control process which is likely to be lengthy if you would traditionally deploy a config to every end point. This could be reduced by reducing the number of in scope end points. Let's say this application was going to 100 people of the total 100,000 endpoints. You could push out a config with just your new process start actions under a quicker change control process and have those actions live quicker. The "to be merged" config can be pushed out using any ESD tool, and the agent will seamlessly combine the new "to be merged" config with the existing config, and your application dependant process start actions are already.
There are many use cases for this, you may want to keep all application settings separate in an Application only config. Or do you need to separate out your business units? They could have a specific config that only relates to them that sits above your baseline config, giving you the ability to distribute them separately.
Configuration Layering Example:Open your Baseline configuration in the normal way. Enable a new FR4 feature - "Change Tracking" this is a great new feature that should be a best practice to enable anyway in any and all config's and is seen in a few places that can prove to be helpful later on.
Click on the "Enable Change Tracking" button.

Click on the Manage Layers Tab, then click on the Add Button.

This will then open the "Add a layer" window.



Click on the Down arrow next to the Add button at the bottom. Clicking on the add button directly defaults to opening an .aemp file from disk. The arrow allows you to select opening a config from the mgmt. centre or sccm, and hence if that’s where you're "to be layered" configs are then use this. Select your "to be layered" config as if you were opening any config. 
Select your configuration, as per the Applications config, which will then take you to the Add Layer screen.
Anything underlined is a link. Following the link in the Name column will take open the application config in the EM Console. Any errors reported can be viewed following the link in the Errors column, and if you have enabled change tracking you can view the history of the config you are layering over the top by using History link:
The result is that my base config now has the process start actions from the separately created applications config.



Now I can save this config back to the management centre in the normal process as the next version. Doing this will keep the layer manageable as a separate layer. The layered can be easily rolled back, by clicking on the Rollback button, this shows you the current version that is layered.


Don't think you just click on OK here, this won’t de-layer this current layer, you have to find a previous version. Click on the layer, then click on browse and find a previous version of this config i.e. version 1.

Now it shows you what the current and the rollback version is, it does its analysis and shows any errors, if all good, it rolls back to version 1 of this config.

Clicking on the Manage button allows you fully merge the config in and make it permanent . This then removes the layered concept such that this layer cannot be managed separately it becomes a single config that needs to be saved as per normal.

Configuration Merging Example.

In my example I have already deployed my baseline configuration using our ESD. But now I need to push out an updated small configuration update. Now admittedly I could just update the baseline config and deploy that, but as per the example given above that may not always be the best option.
So first thing is you need an 8 FR 4 version of the agent. Secondly you need an accompanying manifext.xml file that configures the merge process. To do that you need to use the manifestgen tool. The console help file said that this was in %programdata%\AppSense\Environment Manager\MergeConfigs, however it may have just been me but I could only find it actually on the personalisation server in %programfiles%\AppSense\Environment Manager\Console\ManifestGen.exe

I copied this locally to an endpoint into %programdata%\AppSense\Environment Manager\MergeConfigs and ran it from there. But there are switches meaning you can run it from anywhere and add the options to make it work once the manifest.xml is generated and deployed with the configuration.aemp file to the same local location on the endpoint that I have manually run it in for this example. I suggest you look at the help on this command and see the options that are available.

Thirdly you need to be aware that the merged config has to be an .aemp file, it can’t be another MSI of the config, so you will need to "Save As" your config in the console to disk, then use your  ESD to deploy this with your manifext file, into  %programdata%\AppSense\Environment Manager\MergeConfigs on your endpoint.

If you have auditing enabled add events 948x to alert on all merge actions.

To start I have a normal configuration deployed as normal. I have additionally created an applications.aemp file and saved it to disk. Now I need my manifest xml file. If this file is created remotely it needs to be deployed with the applications .aemp file. In this example I have already placed the applications.aemp file in the \mergedconfigs folder on the end point.
Now on the endpoint open an elevated command prompt and enter your manifestgen command. Here is where you need to review the helpfile for the various options available to you. This example will just use the simplest command. But you can specify output locations of you were running this on a personalisation server in preparation to deploy the manifest, you can likewise define what config is your base etc.
I have run manifestgen *.aemp.

This merges all *.aemp files in the \mergedconfigs folder with the existing configuration. This will create a new merged_configuration.aemp in %programdata%\AppSense\Environment Manager which is now effectively the new config file, which includes what was in the original configuration.aemp file and now the merged applications.aemp.
 In addition the agent creates a file called last_merge_manifest.xml that when opened shows the result of the last successful config merge attempt.

If the merge fails it will created a "failed_merge_manifest.xml" file, and likewise write to the event log defined in auditing.

So there you have two examples of many were you could use either merging or layering, or both.

No comments:

Post a Comment