Skip to main content

GPO and Performance : Part 4

 Farm vs. Active Directory

Citrix policies, i.e. policies applying to the VDAs, can be stored in these two locations:

  • Farm (database)
  • Active Directory and Sysvol (Group Policy)

Both types of policies can be used together. Their settings are joined on the client by the VDA.


Settings configured in Group Policy have precedence over farm settings. Settings are applied in the following order (highest priority last):

  • Local
  • Farm
  • Site
  • Domain
  • OU

Policy Refresh

Farm Policy

New or changed settings are distributed to VDAs:

  • When the VDA registers with a DDC
  • When a user logs on

These events trigger a BrokerAgent CONFIGURATION SET event. BrokerAgent.exe writes changed farm policies to %ProgramData%CitrixPvsAgentLocallyPersistedDataBrokerAgentInfo<GUID>.gpf. BrokerAgent.exe then triggers a policy evaluation via CitrixCseClient.dll. This causes CitrixCseEngine.exe to process policy (see below).

Group Policy

Group Policy is updated following the regular Group Policy cycle with an additional refresh at session reconnection added by Citrix:

  • Computer startup
  • User logon
  • Background refresh
  • When triggered by gpupdate
  • Session reconnection

Citrix Group Policy Client-Side Extension (CSE)

In order to hook into Group Policy operations Citrix adds the client-side extension CitrixCseClient.dll. The Citrix CSE is configured in such a way that it is called every time Group Policy is applied. Its main task is to notify the Citrix Group Policy Engine service (see below).

In addition to that the CSE checks the following undocumented registry values in HKLMSOFTWARECitrixGroupPolicy:

  • CseIgnoreCitrixComputerPolicyTrigger
  • CseIgnoreCitrixUserPolicyTrigger
  • CseIgnoreWindowsComputerPolicyTrigger
  • CseIgnoreWindowsUserPolicyTrigger
  • CseIgnoreWindowsBackgroundComputerPolicyTrigger
  • CseIgnoreWindowsBackgroundUserPolicyTrigger

If you want to change how/when Citrix Policy is applied, those values look like a good place to start.

Citrix Group Policy Engine Service

All the important work is done by the Citrix Group Policy Engine Service (CitrixCseEngine.exe). It is notified by the local Citrix CSE (CitrixCseClient.dll) whenever a policy refresh needs to happen. It then combines Group Policy settings with farm settings, applies them and creates RSoP data. Resulting policy settings are written to the registry:

  • Computer: HKLMSOFTWAREPoliciesCitrix
  • User: HKLMSOFTWAREPoliciesCitrix<SessionID>User

In addition to generating the resulting policy values the Citrix Group Policy Engine Service creates several cache and helper files: actual policy settings are stored as GPF files in %ProgramData%CitrixCseCache. Rollback and RSoP information is written to Rollback.gpf and Rsop.gpf respectively in %ProgramData%CitrixGroupPolicy.


GPO and Performance : Part 3


Group Policy offers four ways to control where the settings defined in a Group Policy Object (GPO) are applied:

  • Organizational units (OUs)
    • Group user/computer objects in OUs
    • Link GPOs to OUs
  • Security
    • Change GPO security so that the GPO applies to specific groups
    • Required permissions: read + apply group policy
    • Works not only for users, but also for computer accounts
  • WMI filters
    • Specify a WMI query
    • The GPO is applied only if the query returns true
    • Applies to entire GPOs
  • Item-level targeting (ILT)
    • Specify targeting criteria
    • A setting is applied only if the criteria match
    • Applies to individual settings (in case of registry settings: can also apply to a collection of settings)
    • Available for Group Policy Preferences (GPPs) only, not for Policies

Out of these four, two are interesting in terms of performance: WMI filters and item-level targeting. We are going to dedicate the rest of this article to them.

How to Measure WMI Query Performance

The execution time of WMI queries can be measured easily by executing the query through the PowerShell cmdlet Measure-Command. For increased accuracy we let the query run a thousand times. The command looks like this (the actual WMI query is bold):

{for($i=0; $i -lt 1000; $i++)
{Get-WmiObject -query “SELECT * FROM Win32_OperatingSystem WHERE BuildNumber > ‘7000’“}}
| select TotalMilliseconds

Execution Time of Popular WMI Queries

Query Execution (ms) Description
SELECT * FROM Win32_OperatingSystem WHERE BuildNumber > ‘7000’ 17 Require at least Windows 7
SELECT * FROM Win32_OperatingSystem WHERE OSArchitecture = ’64-Bit’ 18 Require 64-bit Windows
SELECT * FROM Win32_Keyboard WHERE Layout = ‘00000407’ 8 Require German keyboard layout
SELECT * FROM Win32_ComputerSystem WHERE Name LIKE ‘vpc-%’ 7 Computername starts with a certain prefix
SELECT * FROM Win32_Product where Name like ‘%Adobe Reader%’” 11740 Require Adobe Reader to be installed

As the data in the table above shows, the exuction time of WMI queries is not so bad: 10-20 ms per GPO (remember: WMI filters apply to an entire GPO) typically do not significantly delay logon duration. However, there are exceptions. Most notorious is the Win32_Product WMI class. In a nutshell, do not use it unless you do not care about performance at all.

WMI Query Optimization

A not so well-known optimization is ask WMI for one specific attribute only instead of requesting all fields a class can store. In other words: replace the wildcard with an attribute that is guaranteed to have a value. With that small change the execution times for most queries drop by approximately 50%:

Query Execution (ms) Description
SELECT BuildNumber FROM Win32_OperatingSystem WHERE BuildNumber > ‘7000’ 9 Require at least Windows 7
SELECT OSArchitecture FROM Win32_OperatingSystem WHERE OSArchitecture = ’64-Bit’ 8 Require 64-bit Windows
SELECT Layout FROM Win32_Keyboard WHERE Layout = ‘00000407’ 8 Require German keyboard layout
SELECT Name FROM Win32_ComputerSystem WHERE Name LIKE ‘vpc-%’ 4 Computername starts with a certain prefix
SELECT Name FROM Win32_Product where Name like ‘%Adobe Reader%’” 11640 Require Adobe Reader to be installed

Performance Impact of WMI Filters

To evaluate which impact WMI filters have on Group Policy processing performance I created 100 GPOs with a single GPP registry value each. Then I compared:

  • No WMI filter
  • WMI filter on each GPO, returning true (I used the filter “SELECT Name FROM Win32_ComputerSystem WHERE Name LIKE ‘Citrix-%’

The result:

Group Policy - WMI filter performance

As you can see in the graph above adding a WMI filter to a GPO prolongs processing time for that GPO by about 9 ms. That is more or less the execution time of the WMI query we determined earlier. This tells us two things:

  1. You can gauge the overhead a WMI filter adds to your GPO processing time by timing the filter’s query independently with PowerShell
  2. WMI filter performance is much better than commonly believed

Item-Level Targeting

Item-level targeting (ILT), available for Group Policy Preferences only, can be used to reduce the number of GPOs by combining settings for different sets of users and different types of machines.

A Microsoft blog article says ILT is not inherently harmful and recommends not to run the following ILT evaluations that must work over the network against Active Directory to be evaluated:

  • OU
  • LDAP query
  • Domain
  • Site

Computer security group membership evaluation, however, is fast. Make sure to have installed KB2561285 on Windows Vista and Windows 7, though.


ILT comes with an unnecessary architectural limitation: if you have a GPO with many settings with identical ILT filters, that one filter is run once per setting. The engine is not clever enough to realize that it already knows the answer from the previously applied setting. It would be nice to be able to apply ILT filters to groups of settings. That is possible (groups are called collections), but unfortunately only for registry values.

Performance Impact of Item-Level Targeting

To evaluate which impact GPP item-level targeting has on Group Policy processing performance I created 1 GPO with 100 GPP environment settings. Then I compared:

  • No ILT
  • ILT for computer name on each setting

The result:

Group Policy - item-level targeting performance

The overhead per ILT filter is small: only 2 ms in my test lab. But keep in mind that ILT filters are applied per setting. If you have many settings, you may have many ILT filters, too.

WMI Filters vs. Item-Level Targeting

Execution times for the actual filter queries are not too far apart. However, WMI filters are invoked only once per GPO while item-level targeting may be invoked many times per GPO (increasing total runtime).

WMI filters are stored in Active Directory while ILT filters are stored as files in SYSVOL. If a WMI filter returns false the GPO’s CSE settings files need not be fetched. In order to run ILT filters all CSE settings files need to be fetched because the filters are defined in them.

Continue reading with part 4 of this series.


GPO and Performance : Part 2

Foreground vs. Background Processing

Group Policy can be applied in the foreground and in the background.

Foreground processing occurs when:

  • The computer starts up (computer policy)
  • A user logs on (user policy)

Background processing occurs:

  • Every 90 minutes with a random offset of 0-30 minutes (can be changed)

During background processing many CSEs are invoked even when their settings are unchanged. This is governed by the registry value NoGPOListChanges and policy settings in Computer Configuration > Administrative Templates > System > Group Policy

Synchronous vs. Asynchronous Processing

Group Policy processing can be synchronous (the system waits for completion) or asynchronous (other things happen at the same time). Background processing is always asynchronous. Foreground processing can be either.

In order to reduce perceived startup duration Microsoft changed the default processing mode from synchronous to asynchronous in Windows XP. The caveat is that users are logged on without the full set of policies applied. This is typically not what we want in controlled enterprise environments. To force synchronous processing enable the policy setting Computer Configuration > Policies > Administrative Templates > System > Logon > Always wait for the network at computer startup and logon – which is really horribly named, by the way.

Important: During synchronous foreground processing all CSEs are invoked even if there have been not been any changes to their settings! This disables optimizations and may prolong the total policy processing time. As you may recall from part 1, some CSEs are always invoked, but others are normally only called when their settings have changed.


There are various timeouts built into Group Policy.


Timeout for Group Policy processing from start to end: 60 minutes. If a CSE has not finished after that, it is still being processed, but asynchronouosly. This may affect software installations, for example, but you should not use Group Policy for software distribution anyway. Did anybody even try? I mean, except those poor souls writing technical documentation for Microsoft?


Startup, shutdown, logon and logoff scripts started through Group Policy are limited to 10 minutes. I have not tested what happens when a script reaches that age but I guess it will be terminated along with its child processes.

WMI Filters

WMI filters have a timeout of 30 seconds. Longer running WMI filters are aborted and treated as false.

Drive Mappings

Group Policy Preferences drive mappings are limited to 30 seconds – each.

Important: if target servers are unavailable, logons become slow. The typical delay is 5-7 seconds – per mapping. Trying to map three drives to nonexistent servers in some obscure part of the logon script may easily cost your users 20 seconds. Every single time they log on or start a published application. This happens way more often than one should think it does.

Loopback Modes

Merge Mode

Merge mode forces two Group Policy passes for user settings. The first pass according to the position of the user object in the OU hierarchy (as usual), the second pass according to the position of the computer object in the OU hierarchy. The results from both passes are then merged.

I strongly advise against using merge mode, only partly because of the performance degradation. The main reason I cannot recommend it is that it easily causes confusion as to which settings apply when.

For completeness sake: even with merge mode there is only one pass for computer settings.

Replace Mode

In replace mode the location of the computer object replaces the location of the user object. Apart from that everything happens as always. There is no change in policy processing duration and maintenance is a lot easier than with merge mode.


Group Policy logging can be enabled by setting the DWORD registry value GPsvcDebugLevel to 0x30002 in the key HKLMSOFTWAREMicrosoftWindows NTCurrentVersionDiagnostics. Additionally, and this is easily forgotten, the directory %windir%debugusermode must be created.

Once the registry key is in place and the directory exists logging is enabled (no need to reboot). Log messages are written to the file gpsvc.log in the usermode directory.

Deciphering gpsvc.log is not the easiest task. This 7,700 word article on Microsoft’s Ask the Directory Services Team blog tries to help.

Group Policy Preferences logging can be enabled through Group Policy. Take a look at these settings: Computer Configuration > Policies > Administrative Templates > System > Group Policy > Logging and tracing.


The Group Policy service is single-threaded, so it does not benefit from multiple CPUs. Only exception: during background processing user and computer run in separate threads.

Disabling GPO Sides

Let’s conclude this post by answering the following question: Is it worth disabling the computer or user side of a GPO?

Group Policy Settings Details tab 2

I must admit have applied this “optimization” since the days of Windows 2000. The basic idea is that if Group Policy has less things to worry about processing should be faster. So, if we have GPOs that only contains user settings anyway, why not disable the computer side of that GPO, and vice versa?

To determine the effects of disabling one GPO side I created 40 GPOs and measured the processing time per GPO. Then I disabled each GPO’s user side and repeated the process. The result:

Disabling GPO sides

As you can see, the performance gain of disabling one GPO side is negligible.

This is because if a policy side is unused, the only overhead will be in querying Active Directory to determine that, and the same query must be performed to view the disable option as the one that occurs to determine whether any CSEs have been implemented for that side of the GPO.

Continue reading with part 3 of this series.

GPO and Performance : Part 1

Gpupdate /force is for wimps!

Say you have changed a Group Policy setting in the domain and want to test its effects on a member computer. You open a command prompt and type:

gpupdate /force

Please pause and think this over before hitting enter. Why the /force switch? To show that stupid machine who is its master? Are you one of those people that click Apply before they click OK? Do you wear both belt and suspenders? Of course you do not! So let us take a look at the help text for the /force parameter:


Reapplies all policy settings. By default, only policy settings that have changed are applied.


That is quite telling. Group Policy keeps track of what has been applied and does not reapply settings that are already present. Nice! So why would we override this optimization? We would not. Using /force typically is only required when your Group Policy infrastructure (i.e. AD and/or DNS) are broken. Go fix it instead of telling poor old Group Policy to forego optimizations!


Group Policy may seem like a monolithic beast to you, but in fact, it is not. It is more like a framework that can be extended quite easily. Microsoft provides the engine and a significant set of modules. Vendors like Citrix add their own.

To make things sound more elaborate and bestow yet another acronym on us modules are not called modules, they are called client-side extensions (short: CSEs). All of these nodes in Group Policy Editor are individual CSEs:

Group Policy editor with nodes highlighted

CSE Count

Microsoft keeps adding new capabilities to Group Policy. The number of CSEs that ship with the operating system changed quite significantly over time:

  • Windows 2000: 9
  • Windows XP: 13
  • Windows 7: 42
  • Windows 8.1: 47

CSE Registration

CSEs live in DLLs that are registered in the registry key HKLMSOFTWAREMicrosoftWindows NTCurrentVersionWinlogonGPExtensions:

Registry Editor - GPExtensions

CSEs are identified by GUID. Important values per CSE (GUID) registry key:

  • DllName
  • EnableAsynchronousProcessing
    • Determines whether or not group policy waits for the CSE to complete.
    • Default: 0 (= synchronous)
  • ProcessGroupPolicy/ProcessGroupPolicyEx
    • Function in the DLL to be called when Group Policy processing is passed to the extension
  • NoMachinePolicy
    • Determines whether or not the client extension will process a group policy when a machine policy is being applied.
    • Default: 0 (= process)
  • NoUserPolicy
    • Determines whether or not the client extension will process a group policy when a user policy is being applied.
    • Default: 0 (= process)
  • NoSlowLink
    • Determines whether or not the client extension will process a group policy when a slow link is detected.
    • Default: 0 (= process)
  • NoBackgroundPolicy
    • Determines whether or not the client extension will process a group policy when a background refresh of the group policy occurs.
    • Default: 0 (= process)
  • NoGPOListChanges
    • Determines whether or not the client extension will process a group policy when there are no changes between the cached list of GPOs previously processed and the current list.
    • Default: 0 (= process)
  • PerUserLocalSettings
    • If enabled, user policies are cached on a per-user and per-machine basis.
    • Default: 0 (= disabled)
  • RequiresSuccessfulRegistry
    • If enabled, requires the successful registration of client-side extension components to occur before it processes a group policy.
    • Default: 0 (= disabled)

CSE Processing Order

Client-side extensions are processed in the following order: administrative templates first (i.e. policy settings that are simply written to the registry). Everything else afterwards, in numerical order of the CSEs’ GUIDs. On Windows 8.1 the order is as follows:

  • Administrative templates
    • GUID: 35378EAC-683F-11D2-A89A-00C04FBBCFA2
  • Wireless Group Policy
    • GUID: 0ACDD40C-75AC-47ab-BAA0-BF6DE7E7FE63
  • Citrix Group Policy
    • GUID: 0D0C7034-2EBD-4A87-A9B9-9015E3F2E6E0
  • Group Policy Environment
    • GUID: 0E28E245-9368-4853-AD84-6DA3BA35BB75
  • Central Access Policy Configuration
    • GUID: 16BE69FA-4209-4250-88CB-716CF41954E0
  • Group Policy Local Users and Groups
    • GUID: 17D89FEC-5C44-4972-B12D-241CAEF74509
  • Group Policy Device Settings
    • GUID: 1A6364EB-776B-4120-ADE1-B63A406A76B5
  • Folder Redirection
    • GUID: 25537BA6-77A8-11D2-9B6C-0000F8080861
  • Citrix Profile Management
    • GUID: 26F29E43-DA55-459d-A045-5FEB25F8AB15
  • Microsoft Disk Quota
    • GUID: 3610EDA5-77EF-11D2-8DC5-00C04FA31A66
  • Group Policy Network Options
    • GUID: 3A0DBA37-F8B2-4356-83DE-3E90BD5C261F
  • QoS Packet Scheduler
    • GUID: 426031c0-0b47-4852-b0ca-ac3d37bfcb39
  • Scripts
    • GUID: 42B5FAAE-6536-11d2-AE5A-0000F87571E3
  • Remote Desktop USB Redirection
    • GUID: 4BCD6CDE-777B-48B6-9804-43568E23545D
  • Internet Explorer Zonemapping
    • GUID: 4CFB60C1-FAA6-47f1-89AA-0B18730C9FD3
  • RemoteApp and Desktop Connections
    • GUID: 4D2F9B6F-1E52-4711-A382-6A8B1A003DE6
  • Work Folders
    • GUID: 4D968B55-CAC2-4FF5-983F-0A54603781A3
  • Group Policy Drive Maps
    • GUID: 5794DAFD-BE60-433f-88A2-1A31939AC01F
  • Group Policy Folders
    • GUID: 6232C319-91AC-4931-9385-E70C2B099F0E
  • Group Policy Network Shares
    • GUID: 6A4C88C6-C502-4f74-8F60-2CB23EDC24E2
  • Group Policy Files
    • GUID: 7150F9BF-48AD-4da4-A49C-29EF4A8369BA
  • Group Policy Data Sources
    • GUID: 728EE579-943C-4519-9EF7-AB56765798ED
  • Group Policy Ini Files
    • GUID: 74EE6C03-5363-4554-B161-627540339CAB
  • Windows Search Group Policy Extension
    • GUID: 7933F41E-56F8-41d6-A31C-4148A711EE93
  • Internet Explorer User Accelerators
    • GUID: 7B849a69-220F-451E-B3FE-2CB811AF94AE
  • Security
    • GUID: 827D319E-6EAC-11D2-A4EA-00C04F79F83A
  • Deployed Printer Connections
    • GUID: 8A28E2C5-8D06-49A4-A08C-632DAA493E17
  • Group Policy Services
    • GUID: 91FBB303-0CD5-4055-BF42-E512A681B325
  • Group Policy Folder Options
    • GUID: A3F3E39B-5D83-4940-B954-28315B82F0A8
  • Group Policy Scheduled Tasks
    • GUID: AADCED64-746C-4633-A97C-D61349046527
  • Group Policy Registry
    • GUID: B087BE9D-ED37-454f-AF9C-04291E351182
  • 802.3 Group Policy
    • GUID: B587E2B1-4D59-4e7e-AED9-22B9DF11D053
  • Windows To Go Startup Options
    • GUID: BA649533-0AAC-4E04-B9BC-4DBAE0325B12
  • Group Policy Printers
    • GUID: BC75B1ED-5833-4858-9BB8-CBF0B166DF9D
  • Windows To Go Hibernate Options
    • GUID: C34B2751-1CF4-44F5-9262-C3FC39666591
  • Group Policy Shortcuts
    • GUID: C418DD9D-0D14-4efb-8FBF-CFE535C8FAC7
  • Microsoft Offline Files
    • GUID: C631DF4C-088F-4156-B058-4375F0853CD8
  • Software Installation
    • GUID: C6DC5466-785A-11D2-84D0-00C04FB169F7
    • GUID: CDEAFC3D-948D-49DD-AB12-E578BA4AF7AA
  • Internet Explorer Machine Accelerators
    • GUID: CF7639F3-ABA2-41DB-97F2-81E2C5DBFC5D
  • IP Security
    • GUID: E437BC1C-AA7D-11D2-A382-00C04F991E27
  • Group Policy Internet Settings
    • GUID: E47248BA-94CC-49c4-BBB5-9EB7F05183D0
  • Group Policy Start Menu Settings
    • GUID: E4F48E54-F38D-4884-BFB9-D4D2E5729C18
  • Group Policy Regional Options
    • GUID: E5094040-C46C-4115-B030-04FB2E545B00
  • Group Policy Power Options
    • GUID: E62688F0-25FD-4c90-BFF5-F508B9D2E31F
  • Audit Policy Configuration
    • GUID: F3CCC681-B74C-4060-9F26-CD84525DCA2A
  • Group Policy Applications
    • GUID: F9C77450-3A41-477E-9310-9ACD617BD9E3
  • Enterprise QoS
    • GUID: FB2CA36D-0B40-4307-821B-A13B252DE56C
  • ProcessConnectivityPlatform
    • GUID: FBF687E6-F063-4D9F-9F4F-FD9A26ACDD5F

Changing CSE Processing Order

While the order in which CSEs are processed is deterministic, there is no way to change it. This means that if you want to set a registry value (CSE name: Group Policy Registry) before you run a scheduled task (CSE name: Group Policy Scheduled Tasks) you are out of luck.

CSE Overhead

Each client-side extension that is called during Group Policy processing adds a certain overhead. After all, the underlying DLL has be to loaded, initialized and so on. These are the minimum processing times of some popular CSEs as measured in my lab:

Group Policy CSE processing times

CSE Settings Storage

How client-side extension settings are stored in the domain is really up to the developer of the CSE. Microsoft primarily uses these two formats:

  • Registry.pol
    • Where used: administrative templates
    • File location: \<domain>SysVol<domain>Policies<GPO-GUID>[User|Machine]registry.pol
    • Binary format (MSDN documentation)
    • SDM Software have a free viewer utility
    • Here is a VBScript to read and modify registry.pol files
  • XML
    • Where used: Group Policy Preferences
    • File location: \<domain>SysVol<domain>Policies<GPO-GUID>[User|Machine]Preferences<CSE name><CSE name>.xml

Performance Impact of CSEs Spread Across GPOs

Group Policy settings are stored on the domain controllers in one file per CSE and GPO. If a CSE’s settings are spread across GPOs, the number of files that have to be fetched by the client during Group Policy processing increases. This may adversely impact Group Policy processing, especially if a client is talking to a domain controller over a slow WAN link.

To test the effects of CSE settings spread across GPOs I compared the processing time for two scenarios:

  • 20 GPP environment settings in one GPO
  • 20 GPP environment settings, each in its own GPO

CSE processing time when spread across GPOs

As you can see, the overhead per GPO is about 3.5 ms – in a LAN environment. Things may be very different in a WAN or if the domain controller hosting the settings files responds slowly due to high load.

Like this article? Go on reading part 2!


Microsoft Locks some Group policy options to enterprise editions #WIN10

Today, we surprisingly discovered that Microsoft has secretly changed the availability of some Group Policy options in Windows 10 version 1607. Windows 10 version 1607 “Anniversary Update” has reduced the control via Group Policy that you have in Pro edition. Pro edition users have lesser options available compared to version 1511, so many behaviors of the OS cannot be controlled.

If you open the Group Policy management console and read the description of certain policy settings in Windows 10 build 14393, you will find out that the options mentioned below are NO LONGER AVAILABLE for Windows 10 Pro users. They are locked down to Enterprise and Education editions only:

    • The ability to disable the Lock screen
      In Windows 10, the Lock Screen displays fancy backgrounds and some useful information like clock, date and notifications. It appears before you can pick a user account to sign in. When you lock your computer, again you see the Lock screen. After you dismiss the Lock screen, you get the logon screen where you authenticate. As the Lock screen is being gradually merged with the Logon screen, Microsoft has eliminated the option for Pro users to disable it. In Windows 10 version 1511, you could disable it with a simple Registry tweak. Now, if the user is running the Home or Pro editions of Windows 10, this option is not available. Windows 10 disable lock screen
    • Do not show Windows tips
      The same applies to the Group Policy “Do not show Windows tips” which could be used to disable help tips and introductory toast notifications in Windows 10. These can get very annoying for experienced users. Windows 10 disable windows tips
    • Turn off Microsoft consumer experiences
      Using this option, you could prevent Windows 10 from automatically downloading and installing promoted apps like Candy Crush Soda Saga, Flipper, Twitter, NetFlix, Pandora, MSN News and many other potentially unwanted apps and games. Now you can’t prevent these apps from being automatically downloaded and installed if you are using Windows 10 Pro or Home editions. The policy setting (or Registry setting) has no effect in these editions. consumer experience Starting with Windows 10 Anniversary Update, you can only control unwanted apps in Enterprise and Educations editions of Windows 10. This behavior was confirmed when I upgraded my Windows 7 Professional to Windows 10 Pro and many unwanted apps installed automatically from the Store.

It’s a shame that Microsoft decided to make Windows 10 Pro behave so unprofessionally. These changes make the Pro edition far less attractive for business users. Those who rely on Windows for professional use will have to tolerate random apps and games from the Store being installed on their work PC. By doing these changes, Microsoft is directly forcing these customers to get the higher priced Enterprise or Education editions which are only available through volume licensing. Volume licensing is not only expensive, complicated but requires you to purchase a minimum certain number of licenses.

Microsoft is provoking those who cannot afford volume licensing to pirate the Enterprise or Education editions of Windows 10. These editions now seem to be the only editions that still offer full control over installation of unwanted apps, besides telemetry and privacy intruding features. All the other editions of Windows 10 act like malware.

What do you think of these changes? Do they affect your opinion of Windows 10? Did you expect such feature changes across editions now that Windows is a service?

Installing Belgium EID Middleware – Deploy Silent


1) Make sure KB3125574 is installed otherwise the silent installer will not work on Windows 7 SP1

2) Install Belgium e-ID manually on a windows 7 PC
3) Installer asks to install Drivers. When you accept it it will install certificate on a local machine store
4) Then using mmc extract the certificate from local machine Trusted Publisher Store that is installed after installing SmartCard Drivers Software
I am using ps1 script to install the sofware via SCCM Application
In script I am installing certificate by using this function:
function Import-Certificate
		[IO.FileInfo] $CertFile = $(throw "Paramerter -CertFile [System.IO.FileInfo] is required."),
		[string[]] $StoreNames = $(throw "Paramerter -StoreNames [System.String] is required."),
		[switch] $LocalMachine,
		[switch] $CurrentUser,
		[string] $CertPassword,
		[switch] $Verbose
        if ($Verbose)
            $VerbosePreference = 'Continue'

		if (-not $LocalMachine -and -not $CurrentUser)
			Write-Warning "One or both of the following parameters are required: '-LocalMachine' '-CurrentUser'. Skipping certificate '$CertFile'."
			if ($_)
                $certfile = $_
            $cert = New-Object System.Security.Cryptography.X509Certificates.X509Certificate2 $certfile,$CertPassword
			Write-Error ("Error importing '$certfile': $_ .") -ErrorAction:Continue
		if ($cert -and $LocalMachine)
			$StoreScope = "LocalMachine"
			$StoreNames | ForEach-Object {
				$StoreName = $_
				if (Test-Path "cert:\$StoreScope\$StoreName")
						$store = New-Object System.Security.Cryptography.X509Certificates.X509Store $StoreName, $StoreScope
						Write-Verbose "Successfully added '$certfile' to 'cert:\$StoreScope\$StoreName'."
						Write-Error ("Error adding '$certfile' to 'cert:\$StoreScope\$StoreName': $_ .") -ErrorAction:Continue
					Write-Warning "Certificate store '$StoreName' does not exist. Skipping..."
		if ($cert -and $CurrentUser)
			$StoreScope = "CurrentUser"
			$StoreNames | ForEach-Object {
				$StoreName = $_
				if (Test-Path "cert:\$StoreScope\$StoreName")
						$store = New-Object System.Security.Cryptography.X509Certificates.X509Store $StoreName, $StoreScope
						Write-Verbose "Successfully added '$certfile' to 'cert:\$StoreScope\$StoreName'."
						Write-Error ("Error adding '$certfile' to 'cert:\$StoreScope\$StoreName': $_ .") -ErrorAction:Continue
					Write-Warning "Certificate store '$StoreName' does not exist. Skipping..."
	{ }
Then I am using this function like this in the script to import certificates:
$ScriptPad = $Script:MyInvocation.MyCommand.Path
$ScriptFolder = Split-Path -Parent $ScriptPad
Write-Host "Try to add certificates..."
$filename = Join-Path -Path $ScriptFolder -ChildPath "cert_fedict.cer"
$filename2 = Join-Path -Path $ScriptFolder -ChildPath "fedict_codesiging.cer"
try {
	Import-Certificate -CertFile $filename -StoreNames TrustedPublisher -LocalMachine
	Import-Certificate -CertFile $filename2 -StoreNames TrustedPublisher -LocalMachine
	Write-Host "Certificates ready`n"
} catch {
	Write-Error "Failed while adding certificate..."
Next using Manage-Drivers.ps1 script from this post we can add the driver silently:
write-host "Installing driver...`n"
. $ScriptFolder\Manage-Drivers.ps1 -DriverSource "$ScriptFolder\BeID Minidriver" -LogName "eID_driver.log"
And finally we can install msi by using this line:
write-host "Installing Belgium e-ID msi...`n"
Start-Process -FilePath "msiexec.exe" -ArgumentList "/norestart /i $ScriptFolder\BeidMW_64_4.1.18.msi /qn /l*vx c:\logs\beid4.1.18.log" -Wait
We can verify if the right version (4.1.18) is installed by using this check
if (gwmi -Namespace root\cimv2\sms -class SMS_InstalledSoftware | ?{$_.SoftwareCode -like "{DB942AEA-93D6-4FE4-8862-180D35A71730}"}) {
    Write-Host "Installation completed`n"
{DB942AEA-93D6-4FE4-8862-180D35A71730} is the product id of the software version 4.1.18 and is different for other versions
PS: Thanks everybody for helping to find this out:
Setup Information:
Setup Type: Windows Installer (MSI)
Deployment Method Used: Windows Installer Command Line (No MST)
Deployment Difficulty: Average
Platform(s): Windows
Credits to  comicsserg

The #1 Extension I use for Strava

stravistix google chrome extension plugin to enhance your strava ride data with new metrics

Formerly known as StravaPlus, the recently updated StravistiX extension for Google Chrome takes all your Strava data and creates a cornucopia of new data sets, comparisons, charts, graphs and more to make the most of your metrics.

Once installed, simply go to your Strava homepage as normal (on Chrome) and you’ll start to notice a few new buttons and options. On the Activity Feed, the “Go To Flyby” feature (shown above) from Strava Labs is conveniently below each activity, whether it’s yours or someone you follow. Click on one of your own activities and the real fun begins…


To get started, download the extension here. Then log into your Strava account and check out the new orange hamburger to the left of your usual tabs. Also note the Flyby link under each ride. Drop down the new menu to access the enhanced settings.


There, you’ll be able to set a massive array of settings for both health and performance zones and criteria. Click on a ride you’ve done and there’ll be a large orange button on the right that says “Show Extended Statistics”. Click that and you’ll see something like this, which takes a lot of the Premium account features and shows them in minute detail:


Keep scrolling until you get number overload.


The StravistiX menu also offers quick access to KOM/CR and Heat Maps currently found in Strava Labs.

StravistiX is the brainchild of Thomas Champagne, a programmer in France, and here’s what he had to say about its development:

“I created it because I started cycling approximately four years ago. I did it as training for freestyle skiing, but I dove into cycling and loved the efforts. And I’m kind of a geek. I’m a computer science engineer, and I’m loving the metrics and measurements of everything I do. The information I wanted about my ride was insufficient or irrelevant on Strava or Garmin Connect or Endomondo, but I wanted it all in one place. Something like an average speed of a ride can tell me nothing, especially if you’re doing a ride of 100km where I may cross a city with red lights and cars that slow me and have a huge impact on my average speed. So I introduced Quartile measurements, which gives a more accurate impression of your average speed at the 75th quartile.”

Thomas explained that quartile speeds essentially measure your average speed in segments, eliminating the fastest or slowest quarters or halves. So, if you hammered for most of the ride but then had to cool down or wiggle through neighborhoods to get home, the 75% quartile measures the fastest 75% of your ride and averages it to show what you were really doing while hammering.

Adding to that is TRIMP (TRaining IMPulse), which takes your heart rate data and calculates the stress load put on your heart by a workout. It’s similar to Strava’s Suffer Score, but more accurate. Another great feature is that you can click on any of these numbers and see the calculations used and a technical description of them.

All of the data is pulled directly from Strava’s website, not via any API, so it’s all done in the background once you load the page, but that means it’s only working through the Chrome extension and not an app. The plugin is free and is constantly being updated. If you like, you can donate through the plugin to support further development. The current list of improved features and metrics include:


  • Zone distribution through charts and tables of:
    • Speed/Pace: Quartiles, standard deviation, …
    • Cadence: Quartiles, Pedaling/freewheel time, Crank Revolutions
    • Heart rate reserve: Quartiles, Training Impulse
    • Power: Quartiles, Variability Index, Punch Factor, Weighted Watts/Kg
    • Grade: Quartiles, Grade Profile, Times and percentages during climbs, flats and downhills
  • Each zones for each data type is customizable in Stravisitix Options.
  • TRIMP (Training Impulse) score. The TRIMP is a number calculated according to the time spent in heart zone, to determine the training load. ( )
  • TRIMP / Hour
  • Ratio of activity: time moving over total time of an activity.
  • Thoughness Score: global involvement score into in the activity. It represents your motivation into activity. This score is based on the ratio of activity, elevation, average speed, and distance. (Coming soon for running)
  • Weighted power cycling
  • Weighted power / kg in cycling
  • Cycling variability index. This index shows activity smoothness in terms of effort Cycling intensity index or Punch Factor.This index indicates you were below or beyond of your current power capacity (Functionnal Power Threshold)
  • Distance display for each bike in activities
  • Choosing the type of default Google map
  • Integration VeloViewer in each of your activities
  • “FlyBy” integration: People who make sports with you.
  • OpenStreetMap flipper. Available osm maps: Cycle, Landscape, Street, Os, Outdoors. Garmin TCX export.
  • Weather for cycling activities


  • Exporting cycling segment effort as Virtual Partner course for your Garmin device or other compatible GPS. File format: .crs, .tcx, .gpx
  • % rank in segments
  • Nearby segments around watching segment.
  • Default order in segments: All, Man, Woman, People I am, My results


  • Integration KOM/CR map
  • Integration of Heat Map Global Strava
  • Hidden challenges or/and roads created in the Dashboard

Inside the new options are links to VeloViewer for additional insights mapping and Segment insights, but those require a Strava Premium and/or VV Pro account to fully enjoy.

Download StravistiX for Chrome here. Thomas says he may develop plugins for Safari and Firefox in the future, but offers no timeline. The project is open source, so if you want to help, reach out via his GITHUB website.