Fix: Can’t install iManage FileSite 64-bit due to installer complaining about mismatched ‘bitness’

Testing FileSite 64-bit, I ran into an issue on my own PC. I had 64-bit Office 2016 installed, but the FileSite installer refused to continue and presented me with the following message:

Dialog box: iManage Work FileSite (x64) requires that your computer has matching bitness with all Microsoft Office producs as well as any other iManage Desktop clients, Aborting Installation...

In an attempt to locate the cause of the issue, I fired up the trusty Sysinternals Process Monitor, and set up a filter to capture activity from msiexec.exe. I then further refined that filter to capture only RegQueryValue operations, and re-ran the installer.

Sure enough, Process Monitor picked up some instances of the installer reading from the registry to determine the ‘bitness’ of Office and other iManage products. In my case, there was a lingering registry entry that led the installer to conclude that I still had the 32-bit version of FileSite installed:

A screenshot of Process Monitor, showing a registry key at HKLMSoftwareWOW6432NodeInterwovenWorksiteClientCommonInstallRootbitness with a value of "X86"

Because I didn’t have any iManage products installed at the time, it was safe for me to delete the entire HKLM\SOFTWARE\WOW6432Node\Interwoven reg key.

The installer then ran successfully after this. Thank goodness for Sysinternals by Mark Russinovich.

Internet Explorer’s dangerous default behaviour when a PAC/WPAD file directs the browser to BYPASS the proxy

Today I became aware of this interesting/potentially dangerous default behaviour in Internet Explorer when you use a proxy configuration PAC/WPAD file. Yes, I know that WPAD is a bad idea for other reasons, too.

To quote the IEInternals blog: “One sometimes surprising aspect of proxy scripts is that they impact the Internet Explorer Security Zone determination…. if a proxy script is in use and returns DIRECT, the target site will be mapped to the Local Intranet Zone.”

This is a non-issue if your PAC file only bypasses the proxy server for internal sites, but if you for some reason need to bypass the proxy for an external site, it’s suddenly running outside of Protected Mode and is without the protections in place that the default Internet Zone settings offer.

Screenshot of a PAC/WPAD file showing the FindProxyForURL function with a single example condition to bypass the proxy for In this case, the code returns the string "DIRECT" if the url matches*

Here’s a test with the settings in the default state, and the PAC file instructing all HTTPS traffic to BYPASS the proxy:

Screenshot of Internet Explorer, browsed to, and File, Properties in Internet Explorer showing that the current zone is "Local Intranet"

The solution to this is to ensure that the following box is un-checked.

Screenshot of the dialog box that appears in Internet Explorer when you go to Internet Options > Security (tab) > Local Intranet > Sites (button). Showing the "Include all sites that bypass the proxy server" option is currently checked/ticked

This setting can be found in Internet Explorer under Internet OptionsSecurity (tab)Local IntranetSites (button)

In a corporate environment, you can disable this “feature” via GPO, under Computer/User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Intranet Sites: Include all sites that bypass the proxy server

Disabling via GPO will result in the checkbox being greyed out:

Screenshot of the dialog box that appears in Internet Explorer when you go to Internet Options > Security (tab) > Local Intranet > Sites (button). Showing the "Include all sites that bypass the proxy server" option is currently greyed out due to the GPO that has been put in place

Another test run after making the above changes, showing the correct zone assignment:

Screenshot of Internet Explorer, browsed to, and File, Properties in Internet Explorer showing that the current zone is "Intranet", and Protected Mode is ON

Post-publishing footnote:

I discovered that you also need to ensure that Automatically detect intranet network is not checked.

Screenshot of the dialog box that appears in Internet Explorer when you go to Internet Options > Security (tab) > Local Intranet > Sites (button). Showing that 'Automatically detect intranet network' and 'Include all sites that bypass the proxy server' are greyed out and un-checked

This can be achieved via GPO under Computer/User Configuration > Policies > Administrative Templates > Windows Components > Internet Explorer > Internet Control Panel > Security Page > Turn on automatic detection of intranet (set to disabled)

Resolving all Group Policy Preferences Variables

On the odd occasion that I need to use variables within Group Policy Preferences, I sometimes find myself wishing that there was a blog post that lists out exactly what the variables resolve to.

For example, does the %ProgramFilesDir% value include a trailing backslash? Or do I need to include one myself?

Sure, you can press F3 to bring up the list of variables, but it doesn’t provide example values:

Group Policy Preferences

I decided to use Group Policy Preferences itself to generate a list of the variables and their values. This was achieved through the INI file extension:

Screenshot of the Group Policy Editor, showing the rows of preference items in the INI Files section

I’ve exported these preference items to XML, so you can import them into a fresh GPO and test for yourself. Get the files here.

Screenshot of the Group Policy Management Console, showing where to drag the XML files in order to import them into the INI Files GPP area

I couldn’t get the User preferences extension to generate an INI file, and ran out of time to troubleshoot, but here’s all the variables pertaining to a Computer policy (I’ve obfuscated some values):

A table showing all of the GPP variables, and their values

Apologies for the image-based table. doesn’t make inserting tables particularly easy.

Automatically Create 40 Event Viewer Custom Views

I still find Custom Views useful when troubleshooting on individual workstations, and I’d recently been wondering if it was possible to push them out via GPP or similar. I started creating some views manually, as a test, but it was taking too long.

I’d recently been working on implementing Palantir’s WEF/WEC setup, and wondered whether I could leverage their legwork to automate the creation of these custom views.

The script I came up with took a fraction of the time to write, as opposed to the manual method. It does the following:

  1. Downloads the Palantir ‘windows-event-forwarding’ repo in ZIP format into a temporary folder
  2. Extracts the Event Log query out of each file in the ‘wef-subscriptions’ folder, and
    turns it into an appropriately-named custom Event Viewer view (XML) file in %PROGRAMDATA%\Microsoft\Event Viewer\Views

2017-11-07 16_51_46-Event Viewer

I love how simple PowerShell makes it to work with XML.

The script needs to be run as an admin in order to create the view files in %PROGRAMDATA%, unless you change the output path in the $templateStoragePath variable. It’ll also need to be able to connect to the Internet to download the ZIP file from GitHub.

I’ve started storing my scripts in my PowerShell GitHub repo rather than as Github Gists, and it’s harder to embed them on View the code via the link below:

Mitigate commodity malware attacks with Windows Firewall rules

There’s so much that can be done with the built-in Windows tools to prevent commodity malware or ransomware attacks before you even spend a cent on 3rd party tools. All of these things can (and should be) combined to create a good multi-layered strategy:

The last point has been on my to-do list for some time now. I was again reminded of it the other day while watching Sami Laiho’s recent Microsoft Ignite session about PAWs.

A lot of email-delivered malware begins with a macro or via DDE attack, and then attempts to connect to the Internet to pull down more nasties.

Today I came across this great blog post by Branden, in which he describes a handy method to prevent applications from communicating with hosts out on the Internet, while still allowing them to communicate within the internal network.

I set about manually creating a list of outbound firewall rules, including a whole bunch to mitigate the application whitelisting bypasses highlighted by the brilliant Casey Smith here. Doing this via the GUI is painful, and I wouldn’t wish it on anybody:

A listing of outbound firewall rules created in Windows Firewall with Advanced Security

Here’s a screenshot of PowerShell connecting to the web, before putting the firewall rule in place:

A PowerShell prompt, running Invoke-WebRequest to, and showing a successful request

And here’s one taken after I enabled the firewall rule:

But PowerShell can still connect to an internal web server:

A PowerShell prompt, running Invoke-WebRequest against an internal HTTP server. Showing a successful response

There are obviously going to be exceptions to these rules, for example to enable your IT staff to access Azure AD or other cloud-based services via PowerShell, but those things should be done from dedicated administrative hosts anyway. This ruleset is more for the general user population.

When the time came to think about sharing this ruleset here on my blog, I discovered that it’s possible to export the rules from the registry and re-import them elsewhere, however that has its own potential issues.

I instead created the following PowerShell script that will generate all of the appropriate rules using the New-NetFirewallRule cmdlet. It’s also much easier to review this script to see what it does, rather than read a registry export file.

You could extend this script to apply the rules directly to the appropriate GPO by using the -GPOSession parameter on the New-NetFirewallRule cmdlet.

As usual, run at your own risk, and test thoroughly before deploying:

The embedded Github Gist doesn’t show up on mobile devices. Here’s a direct link to the raw script file:

Automatically drop your Privileged Access Workstation off the network while it’s unattended

“One of my favorite hobbies is hunting sysadmins” – Hacker of Hacking Team’s network

I only periodically log in to my Privileged Access Workstation to carry out administrative tasks. Although I have restrictive policies applied and Windows Firewall locked down, there’s no reason for that machine to be on the network while I’m not actively using it.

In an attempt to address this, I created two simple scheduled tasks:

1. Disable all NICs when workstation is locked

2. Enable all NICs when workstation is unlocked

Note that these depend on the correct audit logging being enabled on the machine in question, otherwise these tasks won’t trigger:

It also depends on how you use your PAW. If you regularly log out rather than shut down, you will need to add additional triggers to the tasks to handle the log off/log on events.

Import these tasks into Task Scheduler and use them at your own peril. You may run into issues if you don’t store any cached logons and simultaneously require a domain controller to be accessible at logon.

Mitel: The TKB has failed to connect to or has lost connection with the IP console application

Had an issue today where our old IP5550 consoles decided that they wouldn’t communicate with the software on our reception PCs. Looking through the logs, this was the only error I could find:

The TKB has failed to connect to or has lost connection with the IP console application

As it happened, I’d just built a Windows 10 PC and installed the 5550 software. I thought that some incompatibility with W10 was the cause of my issues, but then the second console with software on a Windows 7 PC also decided to flake out.

The solution, after all of my troubleshooting, was to pull the power plug on both of the IP consoles and then plug them back in again. So basic that I should have thought of it earlier.