AppSense EM 8.5 Deep Dive


Published on

Published in: Software, Technology
1 Like
  • Be the first to comment

No Downloads
Total Views
On Slideshare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • To replace top right and bottom images:
    Delete current image
    Click the icon, select the image and click Insert
  • AppSense EM 8.5 Deep Dive

    1. 1. Confidential 1 EM 8.5 Deep Dive 1 David Allen Product Manager
    2. 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. 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. 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. 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. 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. 7. New Logon trigger – Logon Messages
    8. 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. 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. 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. 11. EM Policy Q&A
    12. 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. 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. 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. 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. 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. 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. 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. 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. 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. 21. Windows Personalization Q&A
    22. 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. 23. Personalization Server – Multi-instance installation
    24. 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. 25. Personalization Server – Multi-instance IIS config • IIS needs to distinguish between sites: • TCP port • Host headers • IP addresses of interfaces
    26. 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. 27. Q&A