One of the key new policy setting that came with the Edge 77 ADMX/ADML files is called “Configure Internet Explorer integration”. This setting can be found under “Administrative Settings\Microsoft Edge”. What this policy enabled, in conjunction with other settings, was the ability to enable IE mode for Edge.

While IE Mode for original Edge has always been a thing, this new version is designed to launch Internet Explorer in another tab of the current browser. Meaning users only had to go to another tab of Edge to see a site running in IE Mode. This was opposed to how the original IE Mode worked in Edge where it would launch a full copy of IE in another window.

This new integrated IE tab in Edge Chromium is a far more pleasing user experience as the only visual difference now is a small IE logo in the address bar (see below).

So IT admins could finally allow users to give users both a compatible and modern experience without having to having to using a dual browser environment. While the combination of Traditional Edge / IE was something I talked about at Ignite 2017 (see https://channel9.msdn.com/events/Ignite/Australia-2017/WIN342 ) it still was a far from ideal solution.

The problem was, in first release of v77 of Edge Chromium this feature did not fully work. IE Mode would still open in a separate windows similar to how the original IE mode worked.

Since then I have had feedback from Microsoft and they have confirmed that it was being fixed.

” We want to let you know that we fixed an issue thatâ€s related to this feedback in an upcoming update to Microsoft Edge. “

Well, we did not have to wait long and as of today Edge Chromium Dev Channel version 77.0.223.0 has been fixed and IE Mode will now work as expected. Now you can run all your old “important” work related web sites without having to run them in a different window (see below).

But serious, this is a fantastic feature that should remove a lot of barriers for most origination use Edge Chromium as a single browser strategy once it is released.

See https://docs.microsoft.com/en-us/DeployEdge/edge-ie-mode for more information on how to implement IE Mode for Edge Chromium.

However the far more popular browser Chrome from Google also has Group Policy support. So when Microsoft replaced Edge with the Chromium browser a lot IT people started to ask if there would be any similar Group Policy support. As it turns out the answer to this question is YES!

Sean Lyndersay from Microsoft has just recently posted about the new policies that are coming with Edge Chromium edition. In the post he also releases a ZIP file that has a ADM and ADMX templates that can be used to implement the new policy settings. To use the file simple download and unzip the file and copy the ADMX/ADML files into your local C:\Windows\PolicyDefinitions folder. Alternativly you could also copy the files into your Active Directory Central Store, however as these are early templates with limited language support you might want to hold off doing that for now.

Once you have done this open the Group Policy Editor on your computer and you will now see there are new setting under both User and Computer “Administrative Templates > Microsoft Edge”.

Note: This is not to be confused with the existing Group Policy settings for the original version of Edge that can be found under “Administrative Templates > Windows Components > Microsoft Edge”

Thankfully most of the Group Policy setting that were previously in Chrome have been preserved. This give his new version of Edge a huge head start when provide policy support. Especially when compared to the original version of Edge that had servery lacking policy support with only 10 settings.

The ZIP file provided that has been release is only localized for English US and there are no policy settings to manage the update of browser. The update feature will be a very important addition as many organisation might not yet be used to the rapid 6 week release schedule of Chromium.

Also missing are polices to implement IE Enterprise Site Mode list. This is the feature that Edge currently use that can dictate if a web site is opened in the new Edge engine or using the old legacy IE render engine. Unlike previous version of IE Enterprise Site Mode list the new version will run IE in Edge like a normal tab.

“IE mode does not run a separate window. It’s not even a separate tab. It’s fully integrated into Edge”

Once you configure a setting then you will notice that you will get a “Managed by” section appear at the bottom of your Managed tab. As you can see below it also shows the source of where the policy setting. In my example below it lists the domain name of the Microsoft Account I am signed into on my computer.

Then if you then click on this option it will take you to edge://management you then get e description of how the browser is being managed.

Finally you can then open edge://policy and actually see all the setting that have been applied to the browser (similar to Chrome). This will be a super handy feature for help desk users and they can easily and quickly see what policy setting are being applied.

In the example below I just have SmartScreenEnable set to true.

I have been a die hard IE and Edge fan all my life. But the new Edge Chromium browser is certainly a great direction for Microsoft. Now with the inclusion of Group Policy Settings, and the future IE Enterprise Mode it certainly makes it compelling for any corporate to seriously look at making Edge the default corporate browser once it is released.

Its also not just for Windows 10 users as you can now download Edge Chromium for Mac, Windows 7, 8.0, and 8.1 https://blogs.windows.com/msedgedev/2019/06/19/introducing-microsoft-edge-preview-builds-for-windows-7-windows-8-and-windows-8-1/

So if you want to give the new policy setting a try then download Edge Chromium from https://www.microsoftedgeinsider.com/en-us/ and get the zip file https://techcommunity.microsoft.com/t5/Discussions/Early-preview-of-Microsoft-Edge-group-policies/m-p/693929 today.

One of the most notable changes this time is that Microsoft has now dropped the Maximum Password age all together. This means that by default passwords should never naturally expire. 10 years ago suggesting such a change would seem unthinkable but in the past few years many security experts such as Troy Hun have started to recommend this new approach ( https://www.troyhunt.com/passwords-evolved-authentication-guidance-for-the-modern-era/ ). Even the UK government has changed their recommendation to also not have users password expire ( https://www.ncsc.gov.uk/collection/passwords ) . If you are wondering, the logic behind this change is that users that are force to change passwords regularly are by human nature pick something that only change slightly e or simple store the password in secure like a piece of paper. This of course does not mean users will never have to change passwords, and it is important that you have tools in place for suspicious activity with accounts. So when bad activities are detected like a brute force attempt or when passwords match those on know compromised password lists then users should be prompted to change their password.

There are also a number of other minor changes, these changes are summaries conveniently in a spreadsheet contained in the zip file.

Even if you are not yet looking at rolling out Windows 1903 the new guidance and setting can still apply to your older computers and domain policy security settings. So this is a must have download of all security administrators in your organisation.

Download it via https://www.microsoft.com/en-us/download/confirmation.aspx?id=55319

First one is only minor and they have resolved an issues with the policy setting “Turn off app notifications on the lock screen” which can be found under Computer Configuration > Administrative Templates > System > Logo.

The second Group Policy change is they have now added support to configure “Enable Windows to soft-disconnect a computer from a network”. What is “soft-disconnect” you ask? Put simple its a way for a computer to notify application to stop using a specific network interface. If there is an active TCP connection then it will not interrupt that connection. Then after 30 seconds if it still sees that someone or something is using the connection in a significant way (e.g. Skype Call) it will not close the connection. This is far better experience for users, however it can also lead to computer not swapping from wireless to wired connections. It is a default option for Windows 8 and later, so if you want to ensure that network connection are closed then you should disable this policy.

You can download the new update via Windows Update or via the Windows Update Catalog at https://www.catalog.update.microsoft.com/Search.aspx?q=KB4490481 .

You can read more about “soft-disconnect” at https://docs.microsoft.com/en-us/windows-hardware/drivers/mobilebroadband/understanding-and-configuring-windows-connection-manager

With each version release of the OS there is always updated guidance. The differences for which can be found at this blog post https://blogs.technet.microsoft.com/secguide/2018/11/20/security-baseline-final-for-windows-10-v1809-and-windows-server-/ .

It’s a great resource to download and check if all you want to do is stay current with the latest Microsoft guidelines. 

Download at: https://msdnshared.blob.core.windows.net/media/2018/11/Windows-10-1809-Security-Baseline-FINAL.zip

For a full list of policy settings and documentation check out https://docs.microsoft.com/en-us/microsoft-edge/deploy/new-policies

Microsoft has now release a version 2 of the 1803 Admin Pack and while there is no change log, I can confirm that this pack does have the SearchOCR.ADMX file present, thus if you copy the files over top of the existing folder it will no longer cause the error. To update the ADMX/ADML files simply download and install the MSI file provided. Then copy the “Policy Definition” folder from the default “C:\Program Files (x86)\Microsoft Group Policy\Windows 10 April 2018 Update (1803) v2” folder into your companies SYSVOL Policy Definition folder (e.g. \corp.local\sysvol\corp.local\Policies\PolicyDefinitions ).

Note: Some people noted that the Microsoft-Windows-Geolocation-WLPAdm.admx and Microsoft-Windows-Messaging-GroupPolicy.admx were also not included and I can also confirm they are still not provided. However, I don’t believe these files being absent caused any errors.

TIP: If you don’t have any custom ADMX/ADML file just rename the “PolicyDefinitions” folder to “PolicyDefinitions_old” and copy the new folder into the same directory. This way if you are missing any files from the folder then you still have a copy available that you can quickly copy back. If not, just copy the folder over top of the existing files as any custom ADMX/ADML will not be removed.

Download the V2 of the Administrative Templates for Windows 1803 from https://www.microsoft.com/en-us/download/details.aspx?id=56880

The fix is described as:

Addresses an issue that may cause the Mitigation Options Group Policy client-side extension to fail during GPO processing. The error message is “Windows failed to apply the MitigationOptions settings. MitigationOptions settings might have its own log file” or “ProcessGPOList: Extension MitigationOptions returned 0xea.” This issue occurs when Mitigation Options has been defined either manually or by Group Policy on a machine using Windows Defender Security Center or the PowerShell Set-ProcessMitigation cmdlet.

Source: https://support.microsoft.com/en-us/help/4338819/windows-10-update-kb4338819

But as of Windows 10 Insider Preview build 17682 this has now changed and you can now optional install on demand RSAT tools in your Windows client OS.

The great thing about making it part of the Core OS is that it is now kept up to date whenever you receive a new OS version. This means you no longer have to seek out the latest and greatest GPMC version when managing Group Policy as you will always have the latest version installed.

Microsoft is also asking feedback on having RSAT as part of the OS so if you think itâ€s a great idea then definitely put your feedback in via http://aka.ms/rsatfeedback

Source: https://blogs.windows.com/windowsexperience/2018/05/31/announcing-windows-10-insider-preview-build-17682/#sKM6Z3Q4CxWWoaCE.97  

If you want to see how to manage the Start Menu via Group Policy normally you can check out my post at https://www.grouppolicy.biz/2013/06/customising-windows-8-1-start-screen-layout-with-group-policy/

Documentation: This folder has a number of reference documents about the settings including the changes since the last version. This is very handy for keeping track of what guidance has changed

• GPO Reports: These are HTML version of the Group Policy Backups that are provided in the ZIP. They have a full list of all the setting that are applied.
• GPOs: This is a backup of Group Policy Objects that you can import into your own environment that have all the security settings pre-configured. The is a real time saver as you donâ€t have to transcribe the setting from the documentation.
• Local Scripts: This contains some scripts that are used for undoing some security settings on computer that are non-domain joined. This is handy as non-domain joined computer sometimes need to be managed via local accounts and these scripts will remove these restrictions.
• Templates: These contain a few Group Policy ADMX files that are additional security settings that can be applied. Some of these are not traditional (a.k.a. Managed) Group Policy settings so they are not provide with the Out of the Box ADMX files that come with Windows. These include the Local Admin Password Service (a.k.a. LAPS) policy settings, some of the few remaining MSS security settings or the Microsoft Security Guidance Mitigations (e.g. disabling SMB1) settings.
• WMI Filters: This folder contains two WMI filters that can be imported in as GPO WMI Filter. These definitions are used for targeting Group Policy object explicitly to Internet Explore 11 and Windows 10.

Download the Security Baseline now for Windows 10 1803 now via https://blogs.technet.microsoft.com/secguide/2018/04/30/security-baseline-for-windows-10-april-2018-update-v1803-final/

But good news, with the release of the latest version of GPMC for Windows 10 1803 Microsoft has now changed this UI limit value to 20 characters. 

However, Microsoft still warns that:

“Older versions of Windows (such as Windows 98 and Windows NT 4.0) do not support passwords that are longer than 14 characters. Computers that run these older operating systems are unable to authenticate with computers or domains that use accounts that require long passwords.”.

So as always, test carefully before rolling out this setting and be sure that you do not have any legacy device still running on your domain before you set this option. 

Another thing to be cautious of is that if an admin attempts to change this setting via an older version of GPMC then it will force the minimum length back to 14 characters. But this is just another reason why you should always have the latest version of GPMC installed in your environment.

So now you can go forth and force longer passwords for all… HORAA!!! But if you are going to increase the minimum password length consider also implementing some of the other current guidance and for the sake of the users sanity. For example it is now recommend by some that removing maximum password age and complexity (see https://www.ncsc.gov.uk/guidance/password-guidance-simplifying-your-approach  ) is actually more secure especially when you have a longer password that is more conducive to picking a phrase rather than just one word. In any case, the new raised minimum value as an option is welcome change…

Source: https://twitter.com/PyroTek3/status/1000565062501888001

You can now download them now from https://www.microsoft.com/en-us/download/details.aspx?id=45520

This version mismatch until lately this has not been an issues, but the latest version of the ADML has a line missing that does not working with older versions of the SearchOCR.ADMX (see below).

I can confirm with my testing that this is a problem if you still have a copy of the SearchOCR.ADMX file that is as old or older that Windows 10 1503.

So where does this SearchOCR.ADMX file come from if it does not come with Windows out of the box?  The answer is that it’s installed if you have the “Windows TIFF Ifilter” component installed. This then adds the SearchOCR.ADMX file to the local “C:\Windows\PolicyDefinitions” folder.

If you then at some stage copied the “PolicyDefinitions” folder from a computer with the “Windows TIFF IFilter” installed then you will have the “SearchOCR.ADMX” file in your central store. But as the ADMX/ADML policy pack or new version of Windows does not have this ADMX included by default when you overwrite the store this SearchOCR.ADMX file is not updated.

So to fix this problem there are a number of choices:

1. You can hand edit the relevant SearchOCR.ADML file and search for:

<string id=”OCR”>OCR</string>

<string id=”OCREveryPage”>Force TIFF IFilter to perform OCR for every page in a TIFF document

then add the line given below between them:

<string id=”OCR”>OCR</string>

<string id=”Win7Only”>Microsoft Windows 7 or later</string>

<string id=”OCREveryPage”>Force TIFF IFilter to perform OCR for every page in a TIFF document

Note: I donâ€t recommend this method as hand editing a file even as benign as an ADML file can have issues. To fix the problem properly you also have to change it for all language versions would take a lot of effort.

2. If you do not use the Windows TIFF Ifilter group policy setting you can simply delete the “SearchOCR.ADMX” file. This of course means you will not longer have these relevant search settings listed in GPMC editor.
3. You can install the “Windows TIFF IFilter” component on any version of Windows greater than Windows 10/Server 1603 and then manually copy the latest “SearchOCR.ADMX” file to the “PolicyDefinitions” folder. This will give you a matching version of the ADMX and ADML file which will resolve the problem.

So itâ€s a simple enough issue, just remove or replace the relevant “SearchOCR.ADMX” file and the problem will be fixed.

Reference: https://social.technet.microsoft.com/Forums/en-US/cb97affb-9724-457b-a113-32cbd3d53331/searchocradmx-error-after-installing-win101803-admx-templates?forum=winserverGP

You can grab the latest Windows 10 1803 Administrative ADMX templates from https://www.microsoft.com/en-us/download/details.aspx?id=56880

Have you ever found it hard to figure out what tool you need to manage Windows, sometime itâ€s an MMC other times you need to go via Control Panel or you need to launch Server Manager? To help with this Microsoft has now released Windows Admin Center so that IT admin can now use a single UI pane to manage the most common admin tasks.

This tool is a web-based system that works with either Chrome or Edge (sorry IE).

As you can see on the left of the image above there is a wide range of tasks that you can do using this tool, but my most favourite one is the Remote Desktop option that allows you to open a Remote Desktop connection to the server with nothing more than a web browser.

The architecture allows this tool be installed on a single Windows Server OS that publishes the management web page. This computer hosting the web site then acts as a proxy for the management task remotely to multiple computers.

 The good thing about this is that you do not need to install Windows Admin Center on all your computers to be able to management them. But if you are not running Windows Server 2016 or Windows 10 then you will need to download and install the Windows Management Framework v5.1 ( https://www.microsoft.com/en-us/download/details.aspx?id=54616 ).  Another feature of the product is that it integrates with Windows Azure so you can publish you Admin Centre web page online via Azure authentication that allow extra features such as 2FA and conditional access. Once this is done you can have a web page that is accessible anywhere in the world from almost any computer in the world and be able to manage your servers using 2FA authentication.

Alternatively, if you just want to check out the product on a isolated Windows 10 computer is “Desktop Mode”. This version only allows you to access the management web page from the local computer running the service.

On top of the out of the box feature that Admin Center offers it also excellent support for additional add-on meaning that we are likely to see many other first part and third-party product integrates as well. One example of this is the new Storage Migration Tool that is fully manageable using Admin Center. Also, third parties like DataOn, Fujitsu and Squared Up already have third party integrates in the works or available.

Having played with this product for a while now it is great to see that Microsoft is still supporting a first class management experience that can be perform via the UI. While PowerShell is still a important management tool to learn this certainly makes an IT admins life a lot easier by giving them a point and click UI that is easy to use.

For more information and to download the release version of Windows Admin Center go to https://docs.microsoft.com/en-us/windows-server/manage/windows-admin-center/understand/windows-admin-center

It also happens that over the years I have published a number of articles that go into detail as to hope to actually implement some of the items via Group Policy. So below I go though as summary of the essential 8 and link to mine and other post as to how to actually implemented these configurations.

Application whitelisting

Since Windows 7 AppLocker has been the main way that admins can black/white list application. This software is provided out of the box and there is a relatively simple UI in GPMC that allows you to configure what programs are required. Specifically the guidelines calls out “the use of cryptographic hashes, publisher certificates (combining both publisher names and product names), absolute paths and parent folders are all considered suitable if implemented correctly.” which is exactly how AppLocker configures what application to run.

On my site I have two main article about AppLocker, First is the a How to Disable Application using AppLocker post that show you how to block an example application (Chrome) and the other is my AppLocker Troubleshooting guide that helps with common reason as to why AppLocker does not work.

In this case AppLocker is probably the system of choice to implement this, itâ€s free, out of the box and has a wide range of options for blocking applications.

Patch applications

For a Microsoft environment WSUS has long been the go to product for patching Microsoft products (not just the OSâ€s) . It supports patching for a very a wide range of Microsoft Application but give IT Admins control over exactly when and what will be deployed.

The guidance in the ASD article also talks about establishing a priority for deploying patches based on the criticality of the patch.

For example they recommend:

a.      extreme risk: within 48 hours of a patch being released

b.      high risk: within two weeks of a patch being released

c.       moderate or low risk: within one month of a patch being released.

Back in 2011 I wrote a comprehensive post about how to use WSUS to deploy a patching strategy for your organisation https://www.grouppolicy.biz/2011/06/best-practices-group-policy-for-wsus/ .

There are certainly other applications such as SCCM (which leverages WSUS), Altiris and many other systems that can be used to patch your environment. What is important is that you have a method of patching all your third party applications and not just you Microsoft software. As not a lot of vendors have dedicate patching tools this may mean that you have a way to rapidly deploy newer version of the apps when they are release. Either way, make sure you have a way to path ALL you applications (especially Java).

User application hardening

In this case the A.S.D. talk about ways to harden Microsoft Office 2013, 2016 and Java. However, this just talks about common application that you might have installed and should not be treated as an exhaustive list of application to secure. For example if you have Chrome deployed then this can also be secured using Chrome Group Policy settings.

But if you donâ€t have applications that are Group Policy aware then you might want to consider using third party GPO tools such as Policy Pack https://www.policypak.com/ to mange all your legacy applications. One added advantage of Policy Pak is that it allows you to easily manage installed version Java on your computers.

Restrict administrative privileges

Local administration access to computer used to be something that admin gave out like candy to their users. However, for some time now it has been strongly recommended that users are never give local admin permissions or at the very least they should be using separate admin and normal user accounts on their computers.

For a comprehensive artical as to how to security the local admin group on your comptuers see my post https://www.grouppolicy.biz/2010/01/how-to-use-group-policy-preferences-to-secure-local-administrator-groups/

For managing the local admin account on all your computers then also look at another Microsoft tool called Local Admin Password Service (a.k.a LAPS) this allow you to automatically set a random local admin account password on all your comptuers and store it in AD similar to how BitLocker Recovery keys are stored. See  https://technet.microsoft.com/en-us/mt227395.aspx

Patch operating systems

This is pretty much the same as the Application Patching topic as mentioned above. Weather you use WSUS, SCCM, InTune or Windows Update it does not really matter so long as you patch your computers.

If you are using Windows Update natively from Microsoft you can still control the rollout scheduled of new version of patches and OS update via the Windows Update for Business Group Policy setting. See https://www.grouppolicy.biz/2015/11/windows-10-1512-admx-out-now/

What is also very important is that if you are implements a rollout schedule to all your computer based on the importance of the patch is that you should also have a pre-defined test strategy. I also go into how to do this in my article https://www.grouppolicy.biz/2011/06/best-practices-group-policy-for-wsus/ .

Multi-factor authentication

Mult-Factor Authentication also commonly now as Two Factor Authentication is common place for external access to organisation. While Group Policy is not typically used to implement Multi-Factor auth. It still can be used to help with this such as using Group Policy to automatically deploy certificate to all your workstations. These computer certificates can then be used authenticate devices connecting in via IPSec.  For a guide on how to setup automatic computer and users certificate enrolment see https://docs.microsoft.com/en-us/windows-server/networking/core-network-guide/cncg/server-certs/configure-server-certificate-autoenrollment

While not group policy relate you might also want to consider having Multi-Factor authentication implemented in conjunction with tool like CyberArk so that your internal highly privileged accounts are also kept secure. This helps prevents anyone internally from escalating their privileges by resetting a higher level admins password on their accounts.

Daily backups

While you canâ€t directly implement daily backups via Group Policy there are a number of Group Policy settings that you can use to make sure that end-user data that is stored on the local computer is save to the network servers. This then enables you to back the network servers on a daily basis thus achieving the goal of daily backups.

The most common way that this can be done is to use Windows Folder redirection and Roaming Profiles to make sure that all the user data is backed up. See https://www.grouppolicy.biz/2010/08/best-practice-roaming-profiles-and-folder-redirection-a-k-a-user-virtualization/

But also out of the Box with Windows 10 and available in Windows 7 you can use WorkFolders as a way to make sure that the users work files are synchronised with the back-end file server. See https://www.grouppolicy.biz/2013/07/how-to-setup-work-folder-using-group-policy/

Summary

In summary the ASD Essential 8 is a great guide that should be used in your organisation, you may already have implemented some of the points or you might have your own reasons not to carry out some of these items. Either way itâ€s a great starting point to compare agains what you do in your environment to make sure you are secure and stays secure going into the future…

Reference https://www.asd.gov.au/publications/protect/essential-eight-explained.htm 

While it does not seem like there is much in this new version I still always recommend that admin run the latest version of RSAT on their computer to ensure the least amount of problem, especially with Group Policy Management Console.

Whatâ€s new:

• FIXED: DNS server tools are now correctly installed as part of the RSAT package.
• FIXED: Shielding data files and template disks can now be created by their respective wizards in the RSAT package.
• KNOWN ISSUE: The x86 RSAT package may fail during installation on Windows 10 builds older than 17110, and on builds other than the 171xx series.

Also note that Microsoft is already moving away from using RSAT tools for management and with a new tool called codename “Honolulu”. This tool currently only comes with Windows Server 2016 and is a replacement for Windows Server Manage. Its an extensible PowerShell based single management pane tool that can be used to perform many of the admin tasks across multiple servers. For an overview of the tool check out the video below…

In conjunction with this they have also released a new draft security baseline configuration to be used for securing the OS with recommended settings.

In case you missed it Microsoft is no longer support the Security Compliance Manager tool and now only release a Security Templates via individual ZIP files. As such similar information is contained in this tool such as relevant documentation, GPO templates, scripts and even relevant WMI filters.

Notably this version also has a new script that allows you to remove the local admin account restrictions from non-domain joined computers. This is very handy as normally domain joined computers prevent network access for the local admin account, but for non-domain joined it makes managing these devices a lot harder as there is no other way to remotely access these devices.

So if you are using Windows 10 in your organisation then your more than likely be upgrading to this version over the new few month. Therefore it would definitely be good to download and start testing with this template now.

Source: https://blogs.technet.microsoft.com/secguide/2018/03/27/security-baseline-for-windows-10-v1803-redstone-4-draft/

This behaviour was confusing to me as Site Based GPO on the surface seem to have nothing to do with OU’s. But this behaviour is exactly as designed due to the order or precedents that GPO are applied (Local, Site, Domain then OU). As the OU based policy settings take precedence over the Site this also means that OU based blocking will take precedence over Site based GPO as well.

So if you come across this same problem there a number of way that you can work around this problem:

1. The obvious, and remove the the Blocked Inheritance on the OU that the computer object is located.
2. Link the Site based GPO to an OU below the Blocked Inheritance. If you do this you lose the ability to dynamically apply the setting based on the site that the computer is located which then defeats the purpose of having the GPO linked at the site. But if it is something like a Citrix server, then you’ll be able to create a Site based OU (e.g. PAW\SiteName ) and then you can link the GPO to the SiteName OU.
3. You can enabled the “Enforced” option to ignore the “Blocked Inheritance” option.
4. If it is a Group Policy Preference then you can also use the Item Level Targeting to apply the policy only when the computer is in the correct IP address range and/or Site (see below).

Reference for Order of Precedence: https://blogs.technet.microsoft.com/musings_of_a_technical_tam/2012/02/15/group-policy-basics-part-2-understanding-which-gpos-to-apply/

Thanks to Darren Mar-Elia for helping me figure this one out…

Now normally, with any release of Windows 10 I would go though the new list of Group Policy features. But in this new version of Windows 10 there is no new major (or minor) Group Policy engine changes. This meaning that the delivery mechanism of Group Policy has not changed.

But of course, there are many new settings that come with every new version of Windows. So for your easy reference, below is a list of essential reference for any Group Policy Administrator:

• Group Policy Settings Reference for Windows and Windows Server – This is a spreadsheet with that list all the new, updated or replaced Group Policy setting in the 1709 build. Just for the record, there is 55 new Group Policy setting in 1709 which you can find easily in this spreadsheet. You can download this spreadsheet here https://www.microsoft.com/en-us/download/details.aspx?id=25250&751be11f-ede8-5a0c-058c-2ee190a24fa6=True .
• Administrative Templates (.admx) for Windows 10 Fall Creators Update (1709) – This is a downloadable version of the updated ADMX and ADML files that are used to define the new Group Policy settings (See above point). If you already have a copy of Windows 10 1709 installed then you can find these files in the C:\Windows\PolicyDefenitions folder. In the past, you could blindly copy the ADMX/ADML files of the new version of the OS with the old version of the OS but since Windows 10 1703 some of the old policy settings have been removed. This would not cause anything to break, but it might show up as undefined setting the Group Policy Management Console when viewing GPO reports. You can get these files from https://www.microsoft.com/en-gb/download/details.aspx?id=56121
• Remote Server Admin Tools – Yes… Yet another new version of the Remote Server Admin Tools (a.k.a. RSAT) has been released for the Windows 10 1709. These tools are essential for anyone performing admin work with a new version of Windows 10 or Windows Server 2016 in their environment. Generally, I always recommend that any Group Policy Administrator upgrade their RSAT tools to the latest version ASAP. However, I would note that the Windows Server 2016 1709 release of Windows it is *ONLY* available as a Server Core image (see https://docs.microsoft.com/en-us/windows-server/windows-server) . This means that if you are going to install the latest version of Windows Server 2016 then these new admin tools are essential as there is no GUI option to install on the server.
• Security baseline for Windows 10 “Fall Creators Update” – The new 1709 security templates have been added to the Microsoft Security Compliance Toolkit . These provide updated guidance and group policy settings that Microsoft recommends are applied to all new Windows 10 computers. The new settings in this security template all revolve around new 1709 features and details of these changed can be viewed here Security baseline for Windows 10 “Fall Creators Update” (v1709) – FINA
• SMB1 Off by Default – While not a Group Policy specific change I think it is important to note that there are new ADMX setting (see above) that do have have a way to SMB1 client and server protocols. These are especially important as SMB1 is https://support.microsoft.com/en-us/help/4034314/smbv1-is-not-installed-windows-10-and-windows-server-version-1709 disabled in 1709 by default (in some circumstances). If you have not already disabled SMB1 then definitely something to look at ASAP and Microsoft has also published an SMB1 Clearing House list (a.k.a. name and shame list) of vendors that still required SMB1 see SMB1 Product Clearinghouse

Recently, Microsoft has released a how to article explaining how you can use it to restrict network connections to your domain controllers so that only your Privileged Access Workstations can make RDP connection to your domain controllers (see https://blogs.technet.microsoft.com/askpfeplat/2017/07/24/securing-rdp-with-ipsec/ ). Itâ€s a great article that got me to test out the feature myself and I highly recommend that you look at it this article yourself especially if you are setting a dedicated Admin Workstations for your Domain Admins.  

One of the first things that IPSEC needs to do when negotiating the protocol is to authenticate the users and/or the computer. IPSEC can do this is via many ways (see below): 

1. Kerberos – This is on by default way to authenticate any Windows user and computers and is a relatively easy and reliable way of authenticatio
2. NTLM – This is of course the old method of authenticating Windows users and computers and while it is easy to use, it is in no way as strong as Kerberos method.
3. Certificate – This is the uses industry standard PKI certificates again for the computers and/or users. It strength is based on the type of certificate you have deployed, but generally it’s considered very strong authentication. It can however take a lot of setting up as you have to deploy a full PKI environment first and issues the computers and users certificates
4. Preshared key – This option allows you to select a preshred key that you specify as the authentication for IPSEC. As it clearly says (Below) this is a “not recommended” way of setting up authentication for IPSEC. Its only described as being “less secure” than the other authentication methods. This method is really used if you are not communicated with other non-windows computers via IPSEC and you have no other way to authenticate.

(Yes my super-secure password highlighted below ‘ABC123â€)

 Now is also a good time to explain that a few years ago Microsoft released a patch MS14-025 to address how it stored password in AD. In short, the Group Policy Preferences passwords were saved using a 32 bit AES encrypted value. Previous to this hotfix when you set the value in Group Policy you were warned that the password was being only “lightly encrypted”. Microsoft went out if its way to warn you in a blog post about this in 2009 (see https://blogs.technet.microsoft.com/grouppolicy/2009/04/22/passwords-in-group-policy-preferences-updated/) and I also did a post in 2013 (see https://www.grouppolicy.biz/2013/11/why-passwords-in-group-policy-preference-are-very-bad/) explaining how bad it was to use these Preferences password option.  

Then, Metasploit released a module for their toolkit to scan for scanning and decrypting these password value saved in the AD System Volume. So Microsoft released a patch that blocked the UI from being able to make changes to any Group Policy Passwords. Put simply Microsoft drew the line in the sand and prevented anyone from saving Preferences password in the AD SYSVOL. 

So, with the knowledge and Microsoft deliberate attempts to block any sort of “secret” values in AD. So when I then stumbled across this dialogue box that specifically mentioned a preshared Key. This got me thinking about how this key is stored in AD and how Microsoft addressed the same issues of saving the preshared key for IPSEC. 

Firstly you can see (image above) that after you set the value you can still clearly see it in the Group Policy UI. This told me at the very least however they key was stored using encryption and not hashsed. This at the very least told be the valued could in theory be reversed engineered and did get me a bit worried.

 So kept digging into the SYSVOL of the Group Policy Object and almost immediately opened up the “Registry.pol” file to see if it gave any clues to the storage of the key.

 I did a quick “find” in the file for the string ‘ABC123†but could not find it, so I did a quick visual scan for anything that looked like an obfuscated field and to my surprise the key was there in plain text as ‘A B C 1 2 3â€.

 Thatâ€s right, the method of storage of the preshared key for IPSEC is to simply add a space between each character and then just save is in the SYSVOL as clear text. So as far as algorithms go, I think this one could be cracked by my 5 year old…

Update: Thanks to the comment from SODER to my article he explains that the spaces are actually just the way the text is displayed in notepad. Other text editors that display unicode will actually not have any spaces at all.

So the warning message is certinly correct, the preshared key is stored “less secure”. More accurately you could describe it as being not secure at all.

Then, if you have read the blog post by fellow MVP Darren Mar-Elia at https://sdmsoftware.com/group-policy-blog/security-policy/a-new-old-threat-dealing-with-ad-and-group-policy-information-exposure/ you will realise that the System Volume is an open book readable by all computers (and most users) in your Active Directory domain. So, the permission to read the Group Policy Object information that has this preshared key is by default “Authenticated Users” or maybe only “Domain Computers” if you have locked it down. Put simply, assume everyone on your domain can read this value. It must, otherwise how else can your computer read the information required to setup a preshared key authentication in the first place.

 So, to summaries we have a pre-shared key, saved in a place that is readable by all users and computer in the domain and is saved in clear text unicode.

But why is this an issues? Microsoft is clearly warning people that it is “less secure” so let them make the decision about whether to use this option or not. Well, if you remember earlier Microsoft has already gone to the effort of disabling featured that save password values in AD SYSVOL using just light encryption. What I fail to see here in this case why this is really any different.

If I had to guess, this is just a legacy setting that has been around for many years that is used mainly used for testing and/or IPSEC with non-Windows based computers. I am sure the usage rate of such an option if very low. But this does not mean that it is not likely that there are some people out there that are using IPSEC thinking that it gives them some level of protections. 

So let me be clear, in my opinion IPSEC with preshared key should not be considered secure at all. If you have deployed IPSEC using this method of authentication then you really need to look at moving to PKI, Kerberos or event NTLM. Also, at the very least I think Microsoft should address this issues in a similar way to how it prevented people using Group Policy Preferences Passwords.

But donâ€t get me wrong I am not saying IPSEC is not secure, itâ€s just that one of the available method of authentication is not secure. So, if you are going to use IPSEC then for goodness sake NEVER USE PRESHARED KEYS.

To make it easier to disable SMB1 in your environment Microsoft has now release an ADMX/ADML file that adds defines the required registry keys so they can be configured as Administrative Template setting.

To get the SMB1 policy setting visit https://blogs.technet.microsoft.com/secguide/2017/06/15/security-baseline-for-windows-10-creators-update-v1703-draft/ and download the Windows-10-RS2-Security-Baseline ZIP file.

Open the ZIP file and navigate to the “Templates” folder where you then need to extract the SecGuide.adml and SecGuide.ADMX files.

Then copy the two files you extracted ro your “PolicyDefinitions” folder in your SYSVOL. Once you copy these files as with adding any ADMX/ADML file to the Policy Definitions folder you will then see your Group Policies get the new “MS Security Guide” under Computer Administrative templates.

Now, as per the guidance text of the policy you need to do the following and you will have disabled SMB1 on all your Windows computers.

APPLIES ONLY TO: Windows 7 and Windows Servers 2008, 2008R2 and 2012 (NOT 2012R2):

To disable client-side processing of the SMBv1 protocol (recommended), do ALL of the following:
* Set the SMBv1 client driver to “Disable driver” using the “Configure SMB v1 client driver” setting;
* Enable this setting;
* In the “Configure LanmanWorkstation dependencies” text box, enter the following three lines of text:
Bowser
MRxSmb20
NSI

However, as you can see from the chart below that was provided in the FAQ at https://support.microsoft.com/en-us/help/4020089/windows-10-s-faq  the Windows 10 S does not support domain joining much like Windows RT did not and therefore you will not be able to deliver Domain Based Group Policy settings to the OS.

It is however easy to upgrade a Windows 10 S to the PRO version via the Windows Store so if you do purchase a Windows 10 S device you will be able to upgrade it to support Domain Joining and Group Policy if needed.

So does Windows on ARM support Group Policy? Yes, well, almost certainly yes.

As you can see from the two screen shots below from the video Windows 10 on ARM come in a “Pro” SKU which does support Domain Joining as an option. This would almost certainly imply that Windows 10 on ARM will also support the Group Policy settings as all other Windows SKU’s that support domain joining also support Group Policy settings.

So this is great news as it looks like consumers and business will be able to help from Microsoft’s upcoming Windows 10 on ARM Operating System that will have always on and always connected functionality.

Reference https://channel9.msdn.com/events/Build/2017/P4171