Confidential 1

EM 8.5 Deep Dive

1

David AllenProduct ManagerDavid.Allen@appsense.com

Environment Manager 8.5 highlights

• Biggest overhaul of the Console since 8.1• New more reliable logon trigger mechanism• Desktop Settings receives the biggest changes• Removed or simplified overly complex functionality • Numerous issues addressed that couldn’t be

addressed in version 8.4

Common problems addressed in EM 8.5

• Changing the client configuration mid-session• No way to personalize non-exportable certificates• Lack of support for personalizing user mapped network drives• No support for capturing individual files or registry values• Personalizing Windows Explorer views and navigation settings• Capturing Windows and App Credentials inside EM Personalization• Desktop Settings problems across Windows versions and architectures (x86/x64)• Having to rollback all Desktop Settings, not just the those that may have become corrupted• Not being able to use environment and session variables in conditions and actions• Desktop, Task Bar and Start Menu links to non-existent applications• Using SQL scripts to clean out ‘stale’ EM personalization data• No built-in templates for Office 2013 and Office 365• Writing scripting loops to wait for network connection• Scripting Robocopy (instead of using Copy function)• Find and Replace didn’t allow in-place editing

… and many more!

New Logon triggers

• Logon split into 3 sub-triggers• Pre-Session – new trigger that fires once the user profile has been

created but before the user session is started• Pre-Desktop – replacement for the Logon trigger in previous versions

and fires slightly earlier during the logon process• Desktop Created – new trigger that fires once the desktop shell has been

created

Deterministic triggers – behind the scenes

• Logon and Logoff events now use Windows Notification Packages (XP/WS2K3) or SysNotify (Vista/WS2K8 onwards)• EM is now part of the logon chain – no race conditions• No longer reliant on Group Policy for logoff

• Shutdown using a pre-shutdown event from the SCM• No longer reliant on Group Policy

• Session Lock/Unlock, Connect/Disconnect now use SCM events• New ‘Network Available’ trigger, fires after Computer Startup,

uses Network Location Awareness.

S

New Logon trigger – upgrades

• Config upgrades – prompts for upgrades• Yes – upgrades the configuration to 8.5 and the logon triggers• No – upgrades the configuration to 8.5 but not the logon triggers

• Upgrading shows the new sub-triggers• Advanced Configuration Settings provides the option to downgrade to

legacy logon triggers, should you encounter a problem during upgrades• Downgrading converts sub-triggers to nodes• No fixes provided to legacy logon triggers, backward compatibility only

• Switching between modes requires a client system restart• New config won’t be loaded until the rebooted

New Logon trigger – Logon Messages

Network Available trigger

• Added to compliment Computer Startup trigger• Numerous reports of ‘wait for network’ loops in startup trigger

• (Vista, Win7, Win8) uses Network List Manager (NLM) and triggers when “Identified” state of any network received• Windows Firewall uses this to classify network, Public, Private, Domain

• (WinXP) uses of the Windows Network Location Awareness API to obtain the network events for Network Available.• More primitive than NLM, but works along the same lines, used by

Windows for Firewall Policy

• Network Available is not triggered if the service is restarted

Mid-Session config change

• Difficult problem to solve safely– don’t be too clever • Immediate, User Logon or Computer Startup

• Switching modes possible at anytime• Client process “peeks” at the config to determine if it should be loaded,

if not set to “Immediate” then it is ignored

• Controlled by the manifest.xml in the configuration.aemp• <enum name="ProductConfigChange" type="ConfigurationChangeType"

default="UserLogon" />• Non 8.5 configs default to “Immediate”, previous behavior• New 8.5 configs default to “User Logon”

Personalization Override

• It’s Fixed!• Pre-8.5 uses copy operations inside personalization• 8.5 uses a copy operation inside policy

• All the virtual file actions are run inside policy instead of inside the Profile Module which was devoid of any of the environment or options available inside the policy engine

S

EM Policy

Q&A

Windows Personalization

• Desktop Settings + Session Data = Windows Personalization• Configurable outside of Personalization Groups

• Uses the same paradigm as Applications

• Stores Windows settings in user configurable collections which controls the granularity of rollbacks

• Uses more flexible ‘EM Policy Conditions’ rather than the limited inherit, shared and separate model per ‘Windows family’• Provides specific device targeting

• Session Data = Custom Windows Setting• Specify Files/Folders and Registry Keys/Values• Select which Windows versions it applies to

Windows Personalization – under the hood

• Each group of Windows settings equates to one ‘bubble’• Assigning to these to Personalization Groups, means multiple

‘bubbles’ per profile, but are encapsulated in one profile• All ‘bubbles’ are therefore retrieved in one server round-trip

to improve performance – better than 8.4• Personalization configuration now cached to improve

performance (metadata, policy and conditions cache)• Changes to the groups, such as the addition or removal of Windows

settings or conditions will update the cache

Windows Personalization – Logon

• Client requests the configuration (config.aspx)• ProfileConfig.xml, DesktopSettings3.xml and

DesktopSettingsConditions.xml are downloaded (compressed)• DesktopSettings3.xml contains Windows Personalization

definitions• Fixed meta-data for the OOB fixed windows settings, representing

which registry keys/file paths are valid on each Windows version

• DesktopSettingsConditions.xml is the EMX policy configuration that applies to the Windows Settings Groups• Contains a conditions node for each group of Windows settings

S

Windows Personalization – Logon (2)

• DesktopSettingsConditions.xml is loaded using the policy “ConfigurationManager”• Effectively this is loaded into a new trigger named

“DESKTOP_SETTINGS_CONDITIONS”• The policy execution engine trigger and associated nodes are created

• The policy execution engine is then used to• Register a node completion callback, which is fired for each group of Windows

settings, when complete• Initiates execution of the DESKTOP_SETTINGS_CONDITIONS trigger• Executes each node on a separate thread (as per usual with policy triggers)• For each callback that completes with a positive result, the group of Windows

settings is recorded in a listS

Windows Personalization – Logon (3)

• The list of recorded Windows Settings Groups is passed over to the synchronizer in order to make a request for the required groups

• The synchronizer creates a new file in the cache called AppSenseFileFilter.xml • Contain a comma separated list of WSG’s to fetch in the profile – conditions

excluded WSG’s that are not relevant

• Performs a sync down sending the new file for the filtered WSG list• EMPS performs a filtered query based on the file filter• When the data arrives at the client, each fbr per WSG is applied to

the registry according to the Windows version

S

Windows Personalization – Logoff

• DesktopSettingsConditions.xml parsed again• This will have been updated when the config poll is performed

• DESKTOP_SETTINGS_CONDITIONS trigger is run again.• List of WSGs prepared and Desktop Cache is prepared for sync up

• Existing WSGs (at logon) are saved to a temporary area• The Desktop Cache is cleared• WSGs are saved to the cache from the real registry/file system using the list

prepared earlier• Settings applicable by Windows version are added in to the FBR files• Unreferenced files no longer used are deleted

• AppSenseFileFilter.xml created from list of WSGs• Sync up to server

S

Windows Personalization – Config upgrades

• Clean installs match old 8.4 Desktop Settings• Capture the same using conditions rather than ‘OS Family’ (shared/separate model)

• Pre-8.3 configs are not upgraded, use the same config as a clean install• Post-8.3 upgrades the config – you don’t have to keep this, construct your own

• Personalization Groups using global Desktop Settings, which are Shared, are placed in ‘GlobalShared’ Group

• Personalization Groups using global Desktop Settings, which are Separate, are placed into the groups: ‘GlobalXP’, ‘GlobalVista’, ‘GlobalWin7’ or ‘GlobalWin8’ Group

• Personalization Groups with group specific Desktop Settings get placed either in a <PGName>_Shared group if Shared or <PGName>_OS group if marked as a separate setting

• Session Data placed in SessionData WSGs• One per Personalization Group if not global

• Certificates and Credential settings stored in a Security WSG

Windows Personalization – Data upgrades

• Continues to behave as it did previously• Legacy Desktop Settings data is preserved

• Cannot change legacy personalization configuration • Data conversion takes place once 8.5 agent deployed• Converted to the WSG per Personalization Group• Legacy data remains until you are ready to remove it

• Old Desktop Settings data is displayed in Personalization Analysis as [Legacy]

Windows Personalization – Certificates & Credentials

• Certificates and Credentials managed separately• Now Windows Settings in Windows Personalization• New certificate functionality:

• Trusted Root certificates• Non-Exportable Certificates• Certificates with high security keys• No user prompting accepting trusted root and high security certificates

• To resolve certificates held in the registry• Trusted Installer ownership issues – solution was to hive these• Incompatible between NT5 and NT6 – solution hive for each platform type

S

Windows Personalization

Q&A

Personalization Server – Multi-instance

• Install multiple named instances of EMPS on the same machine

• Separate versions and separately patchable• Each instance has a name (instance id), first install is

called “DEFAULT”• Each instance requires a separate web site in IIS

Personalization Server – Multi-instance installation

Personalization Server – Multi-instance installation (2)

• Install instances of EMPS with the following msiexec command:• msiexec /i <pathtomsi> INSTANCEID=<instancename>

TRANSFORMS=<tname> MSINEWINSTANCE=1 /quietwherepathtomsi is the full path of PersonalizationServer64.msitname is an internal transform name - values are “:I01” to “:I16”instancename is the name you want to give the instance

• Alternatively use InstallerCmd.exe which can be found in the Bin directory of a full installation• E.g. InstallerCmd /i <pathtomsi> <instancename> [<optional parameters>]

• Up to 17 instances per server - default and I01 to I16.

Personalization Server – Multi-instance IIS config

• IIS needs to distinguish between sites:• TCP port• Host headers • IP addresses of interfaces

Personalization Server – PoSH configuration

• Post installation SCU cmdlets Get-ApsInstance and Import-ApsInstance are available

• Use Get-ApsInstance to list all instances of product server• Use Import-ApsInstance to load the remaining cmdlets for the

product server and instance you want to configure• Most important cmdlets:

• Get-ApsPrerequisite, Install-ApsPrerequisite - list and install prerequisites• Initialize-ApsDatabase - create or upgrade database• Initialize-ApsServer - set up current server• All cmdlets provide online help (e.g. get-help Initialize-ApsDatabase)

Q&A