1. Confidential 1
EM 8.5 Deep Dive
1
David Allen
Product Manager
David.Allen@appsense.com

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

3. 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!

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

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

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

7. New Logon trigger – Logon Messages

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

9. 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”

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

11. EM Policy
Q&A

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

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

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

15. 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 list
S

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

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

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

19. 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]

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

21. Windows Personalization
Q&A

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

23. Personalization Server – Multi-instance installation

24. Personalization Server – Multi-instance installation (2)
• Install instances of EMPS with the following msiexec command:
• msiexec /i <pathtomsi> INSTANCEID=<instancename>
TRANSFORMS=<tname> MSINEWINSTANCE=1 /quiet
where
pathtomsi is the full path of PersonalizationServer64.msi
tname 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.

25. Personalization Server – Multi-instance IIS config
• IIS needs to distinguish
between sites:
• TCP port
• Host headers
• IP addresses of interfaces

26. 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)

27. Q&A