AppSense Regular Expression for Microsoft Office

I needed to add a new rule to AppSense recently on process start.  I wanted the rule to only run when a Microsoft Office application was run.

Now I usually eat regular expressions for breakfast (with some ketchup on top for good measure).  However I noticed that my regular expression wasn’t working in AppSense and it turned out to be the flavour of Regular Expression that it uses.

You see, I tend to use JavaScript regular expressions or .Net regular expressions.  But AppSense was presumably written in C++ and uses the CAtlRegExp regular expression of the ATL class which is…..lame.  Grouping syntax is different, and so is character matching syntax.

To test my regular expressions, rather than update the AppSense policy and wait for it to deploy to the machine, I just downloaded the regular expression tester from here.

So this was my first attempt – the MfcRegex tool said it was a successful match!  So I plonked it into AppSense:

But wait!  AppSense tries to be clever and escapes the brackets with preceding backslashes (I noticed this in the client debug logs), so this RegEx was failing because AppSense was evaluating it to this:

So by this point I was close to throwing my computer out of the window, until finally I used this syntax which works like a charm:

Notice that I have changed the brackets and slightly altered the syntax.  If you wanted to limit it to a specific version of Office (2010 in my case) you can use a regular expression similar to this:



Create a Code Signing Certificate using Active Directory Certificate Services

Ok, this post is shameless plagiarism from this post.  But I couldn’t risk losing sight of good content.  Thanks (and apologies) go to David Barrett!

Enable the Code Signing Certificate Template

  1. On the appropriate server (e.g. the CA root), open Certificate Services Manager.
  2. In the left pane, select Certificate Templates.
  3. Check for a Code Signing template – by default, this isn’t available.  If it isn’t, add it:
    1. From Action menu, select New -> Certificate Template to Issue.
    2. Select Code Signing, then click OK.

 Grant Permissions for User(s) to Create Code Signing Certificates

  1. From the Certificate Services Manager, right click Certificate Templates and select Manage.
  2. From the list of templates, right-click Code Signing and select Properties.
  3. Select the Security tab.
  4. Any users that should be allowed to create code signing certificates need to be granted Read and Enroll permissions, so add users and permissions as necessary.
  5. Apply changes.

Create a Code Signing Certificate

  1. On the development machine (logged in as a user who has been granted permissions to create a code signing certificate), open Microsoft Management Console.
  2. From File menu, select Add/Remove Snap-in…
  3. From Available snap-ins, select Certificates and then click Add.
  4. Select My user account, and then click Finish.
  5. OK out of the Add/Remove snap-in window.
  6. You will now see Certificates listed in the console view on the left.  Right-click Personal, select All Tasks, then Request New Certificate.
  7. Click Next on the first screen (Before You Begin).
  8. Click Next on the Select Certificate Enrolment Policy screen (Active Directory Enrolment Policy will be applied).
  9. In the Request Certificates screen, tick Code Signing, and then click Enrol.  A certificate will be created and placed in the user’s Personal store.

Browsium Ion and Authentication

I set up a Browsium rule recently to render a SharePoint 2010 site in IE8 Standards mode.

Without the Browsium rule in place the site loaded fine but one of the Web Parts didn’t work.  However when the Browsium rule was enabled, the Web Part worked fine but the user was prompted for authentication when the site initially loaded!  It was as if Browsium wasn’t passing the Windows authenticated credentials during the request.

Specifying AutoAuth

To resolve the authentication issue we can specify an ION profile flag under Advanced Profile Set which details what credentials are sent to the upstream server when automatically replying to an authentication challenge.

Browsium AutoAuth

Browsium Ion, HTTPS and Proxy Authentication

I’ve been playing around with Browsium Ion recently and I was testing a HTTPS URL, trying to force the default ‘Edge’ emulation mode to run in ‘IE8’ emulation mode instead.  For HTTP URLs it worked fine.  However with HTTPS URLS, when a new instance of iexplore.exe launched (presumably after being intercepted and spawned by Browsium Ion) the user was prompted for proxy authentication.  Even upon entering correct credentials it still didn’t authenticate.  After clicking ‘cancel’ dozens of times, the authentication prompt eventually went away and we saw the page rendering successfully in IE8 Emulation mode.

Specifying a Proxy Host and Port

To resolve the authentication issue we can specifically provide a proxy host and port (one that authenticates for the user) by adding the following to Advanced Profile Set for the profile in question:

Browsium Proxy

Disable ‘Managed Mode’ in Mcafee

I was testing an app on a Virtual Machine (a P2V of the client build) and I had a feel McAfee was preventing something from functioning.  To test this I needed to disable ‘Managed Mode’ in Mcafee.  This is how I did it:

Step 1: Login in as an admin user

Step 2: Run: c:\Program Files (x86)\McAfee\Common Framework\x86\FrmInst.exe /forceuninstall

Step 3: Reboot into safe mode

Step 4: Open Regedit and delete:

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\McAfee\ePolicy Orchestrator\Application Plugins\VIRUSCAN8800

HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Network Associates\ePolicy Orchestrator\Application Plugins\VIRUSCAN8800




UIP to blank

UIPMode to 0

Step 5: Reboot

We can now log back in as an administrator and ‘disable’ McAfee via the VirusScan console (Right-Click ‘Access Protection’, click Disable).

Add a Right-click Context Sub Menu

I’ve been creating a few tools recently for a client – scripted tools which perform specific tasks on MSI (Windows Installer) files. Because we’re likely to create multiple tools and I don’t want the context menu to get too long and too ugly, so I decided to add a right-click context sub menu.  Here’s what it produces:


And here’s the registry that made it happen:

If you look closely, you should see that this context menu will only show for MSI files because we use the Msi.Package progid.  You’ll also note that when we export registry into a .reg file like above, all quotes in the registry values are escaped by a preceeding backslash as indeed are all backslashes!  So a quote would be \” and a backslash would be \\!  As an example (taken from above) the value:

mshta.exe \”\\\\server\\pathtotools\\mycustomtool.hta\” \”%1\”

when imported will resolve to:

mshta.exe “\\server\pathtotools\mycustomtool.hta” “%1”