While testing Always On VPN in Windows 10, I discovered an issue where users couldn’t access the Network Connections settings to see what the VPN profile was up to.
Network Connections is accessible in a few ways, including via Control Panel\All Control Panel Items\Network Connections, or ‘Change Adapter Options’ under Settings > Network and Internet > Ethernet. It was locked down, but I wasn’t sure why.
If I changed a user to be a local administrator, I could then access Network Connections. I couldn’t find any reason why it could be locked down, until I stumbled across this old Group Policy Setting:
Based on it’s name, it should be just doing exactly what it says. Plus, the newsest desktop OS listed for support is Windows Vista.
However, as the help explicitly says:
Network Connections still appears in Control Panel and in File Explorer, but if users try to start it, a message appears explaining that a setting prevents the action.
And that’s exactly what it was doing. After removing the setting from being configured and running ‘gpupdate’, I could immediately access Network Connections again.
Another reason to make sure your Group Policy settings are cleaned up – this setting was set over 10 years ago, and took this long to discover and remove!
AKA How to force certain websites when opened in Edge, to instead open in Internet Explorer.
Microsoft Edge is undergoing a big change with the underlying platform being migrated to Chromium – things will change with that (along with a new Internet Explorer mode) but that doesn’t help right now.
Many companies have certain websites they need to use that either require Internet Explorer, or work best in Internet Explorer. This isn’t about what browser is ‘best’, but some solutions were designed with only Internet Explorer in use.
Getting users to use the right website in the right scenario can be a pain, and every user seems to have their own opinion on what browser they prefer to use. Microsoft Edge has a great solution for this – Enterprise Mode. There was also an Enterprise Mode in Internet Explorer that worked in a similar way too, where you could force certain sites to run as a certain version of IE for compatibility reasons.
This is quite easy to set up, but I’ve found the existing documentation rather confusing to follow and doesn’t give an end to end explanation – or documentation is rather outdated and was written when the feature first came out, with a lot of options changing since then.
Enterprise Mode Site List Manager will start off blank. Click the ‘Add’ button on the bottom, type in the URL of the site you want to use (don’t worry about http or https if you want to catch both). You then tell it what to do with that URL – Open in IE, Edge, or do nothing. Since we’re opening everything in Edge except what we want in this list, open in IE11 is the option we want, and leave it at the default IE8 Enterprise Mode (or change this if you need a different compatibility mode).
There’s two parts to maintaining a list – Exporting/Importing lists, and Saving as XML:
Once you have a record to test, go to File > Export. This will save your details into an .emie2 file, and put that somewhere central and safe. The idea is that you’ll need to import that file list to make a change, then export again. If you don’t do this, you won’t have a way for others to get the list of sites and make changes by importing that file at a later date. It has in-built version control (this is important, more later), in the screenshot above you can see it’s version 5.
Then, you can save your URL to an XML file. This is what Edge will read when it launches. Either save this file centrally where everyone can read it (no write access required, just read), or copy it to everyone’s computer locally via GPO. Personally I’ve just put it in a central location.
Step 2 – Configure Group Policyor Intune
I’m using Group Policy, but the Microsoft Documentation mentions Intune is supported too – we’re only changing registry settings, so that makes sense.
Turning on Enterprise Mode can be done at either the Computer or User level, and is under > Policies > Administrative Templates > Windows Components > Microsoft Edge > Configure the Enterprise Mode Site List.
Enable this setting, and in the options enter the path of where your XML is – e.g. \\server\sharename\edge.xml – or C:\Data\edgesettings.xml. Although the Group Policy says URL, it’ll accept UNC paths or drives.
If you’ve used a Computer Configuration setting, gpupdate then reboot (or reboot twice). To tell if the setting has applied, check the value of the registry setting:
SiteList = The path you entered in the Group Policy setting.
If you’re see that, great! Group Policy is working. One caveat if you have System Center Configuration Manager (ConfigMgr) – it can potentially use this setting also as per this technet thread which is exactly what I had. I was testing a user policy, but this was configured at both the user and computer levels so my user setting was being ignored. I’m not sure if this is still used, but worth being aware of.
Version control is also recorded in the registry. It lives under:
regardless of the SiteList being under Computer or User. There’s a few catches with this – first, it’ll only show up after Edge is launched, and you wait ~65 seconds. It’ll show the same version as what’s contained in the XML, which was the version we saw in Enterprise Mode Site List Manager.
If you have the ConfigMgr setting, or have ever had Enterprise Mode for Edge enabled in your environment, then the version might already exist and be higher than what you’ve tried to deploy. On my PC, I saw version 28000 something – that’s a lot of versions.
You’ll need to either delete that value for everyone to start back at 0, then after Edge is launched per user, it’ll update to whatever your XML file contains, or update the version in Enterprise Mode Site List Manager to a higher number than whatever’s out there in your environment.
To change the version in Enterprise Mode Site List Manager, on the computer with it installed navigate to
C:\Users\your username\AppData\Roaming\EMIESiteListManager\ – in that path should be a file called SiteList.xml.
That file should have the first line as <site-list version=”5″> or whatever the current version is, and you can just change that ‘5’ to whatever number you want. Open Enterprise Mode Site List Manager and you’ll see that updated version number, which will then get written +1 to the XML file next time you save it out.
That’s really it – it’s simple, but there are a few catches I ran into when testing. Once this is in place, if a user goes to a site that you’ve listed in the XML, a new window opens in IE and goes to that site instead. It’ll also support subsites, so you don’t need to sent traffic for an entire domain like adamfowlerit.com there, it could be adamfowlerit.com/news and only hits to that subdomain will be triggered.
There’s a few other Group Policy settings around this such as forcing all intranet sites to go to IE, you’ll need to work out what’s best for your environment.
4. Do your normal process of configuring the Group Policy object to target the users you want, run a gpupdate and see the addin silently turn up in Chrome. The only user impact will be a visible Windows logo to the left of the Google Accounts area in the top bar of Chrome.
The policy explicitly states “The ‘Deny all add-ons unless specifically allowed in the Add-on List’ policy setting will still determine whether add-ons not in this list are assumed to be denied.”
However, since a recent update (either Windows 10 1803, or a recent security patch – unsure which!), anything not listed in the Add-On List was being blocked.
Adding an update to the list and allowing it with the ‘1’ value fixes the issue for that particular add-in, but it shouldn’t be working this way.
I even tried disabling the Group Policy setting ‘Deny all add-ons unless specifically allowed in the Add-on List’ but that made no difference. That policy also states: ‘If you disable or do not configure this policy setting, users may use Add-on Manager to allow or deny any add-ons that are not included in the ‘Add-on List’ policy setting.’
Something wacky’s going on – if I find out more I’ll update this post, but if you do use the ‘Add-On List’ GPO for Internet Explorer, be aware of this potential issue. You may need to list all your add-ins into the policy to avoid this.
I’ve also updated all my ADMX files for Win10 1803.
I believe I fixed this by auditing all the IE addins and making sure they were allowed. Somtimes an addin has a prerequisite of another adding being enabled, so you can’t always trust the message you see.
“I’ve lost a document and can’t find it!” is a common phrase that nobody likes to hear. Most people are working in Microsoft Word for their documents, and although it has a bunch of nice features for autorecovering lost work, it doesn’t cover all scenarios.
There’s even a new feature which autosaves your work as you go; as long as the document is in SharePoint Online or OneDrive for Business.
However, it’s still easy for someone to accidentally close a document and say ‘no’ to saving changes, or other scenarios where documents get overwritten with the wrong information. A document management system (DMS) with versioning (such as SharePoint) can help, but I’ve yet to hear of a company that has 100% of their documents at all times in their DMS!
Anyway, after seeing many scenarios of lost work, I thought there might be another method I can implement to help capture lost data. Microsoft Word’s Autorecover function does work quite well, in keeping an ASD file updated at regular intervals (10 minutes by default) which are saved in C:\Users\username\AppData\Roaming\Microsoft\Word\ (by default). I changed this to 5 minutes rather than 10:
Autorecover will update an ASD file in this folder for each document you have open, on the frequency configured above. That file can get closed or lost depending what the user clicks (again, closing and not saving a document is a scenario that will lose the ASD).
My idea was to back up these ASD files also on a 5 minute interval, giving another avenue to restore lost documents. Because the AutoRecover starts at a random time, a script running every 5 minutes would also start at a random time, and together there’d be a 5 to 10 minute window on copying out the backup files, which isn’t a huge amount of work to lose if someone had been working for hours.
Here’s the PowerShell script I wrote. It first sets a few variables that can be configured, then does a cleanup of previous backups. If they’re > 2 days old, backup folders are purged or we’d have an ever growing amount of backups. The 2 day value in (Get-Date).AddDays(-2) can be changed.
Then, it runs a filecheck to make sure there’s ASF files to back up. If not, the script breaks. If files exist though, it then creates the Backup folder, creates a sub folder based on the date/time and then copies the ASD files into that folder.
The format of the folders is set at the very start of the script, and again can be changed to a different format if you prefer.
(note that the File copy section was taken from here). Save the above as a .PS1 script and you’re good to go.
That worked well after a lot of testing, but the next problem was getting it to run on everyone’s computer. Using a Scheduled Task means we can configure it to run however often we like and whenever we like, as well as being able to push out the task via Group Policy. However, you can’t run PowerShell scripts silently just by running a PS1 file when triggered from Scheduled Tasks.
There is a great workaround here which uses a VBS file to then trigger the above PS1 script. the VBS component itself runs silently which in turn runs the PS1 script silently. Here’s a copy of the script in case the link goes dead, but please read the original link for more details:
Set objShell = CreateObject("Wscript.Shell")
Set args = Wscript.Arguments
For Each arg In args
PSRun = "powershell.exe -WindowStyle hidden -ExecutionPolicy bypass -NonInteractive -File " & arg
The final catch is then opening an ASD file when you want to recover something. To open a recovered file, in Word go to File > Info > Manage Document > Recover Unsaved Document (if the Info link is greyed out, open a new blank document first). If you had to navigate away from the default location it shows to open the ASD file, you will probably see this error:
As pointed out here, for some reason Word doesn’t like opening the file unless it’s in the special ‘UnsavedFiles’ location. Luckily you can just copy the ASD file into this folder (which by default is C:\Users\%username%\AppData\Local\Microsoft\Office\UnsavedFiles” ) and then open it as per the above method.
Keep in mind, both the PS1 and VBS files also need to be available to the user, which you may want to also push out by Group Policy. Just make sure the file called by the Scheduled Task exists, or the users will see an error saying the file can’t be found, every single time the script runs.
Update 16th July 2018
I’ve adjusted the script slightly for use in a terminal server environment (RDS or Citrix). The scripts are seperate – yes a master one could be created, detect if it’s a client or server, then run the appropriate parts, but I haven’t done that :)
The only real change is getting the list of logged on users from a broker. I could filter these out to only grab the users on the local box but the script runs within a second anyway and shouldn’t find or do anything if the user profile doesn’t have any backup files.