IIS 7.5, WCF Error: "the requested content appears to be script and will not be served by the static file handler"

Had a problem developing a WCF service to grab data out of Sitecore, which is running on IIS 7.5 in my dev environment. I published the service in the config-free manner, but was getting an error:

the requested content appears to be script and will not be served by the static file handler

After searching around for a bit, I found a post on the MSDN forums that responded to a different error message, but the solution worked for my problem also:

You will need to run ServiceModelReg.exe -i from the “%windir%\Microsoft.NET\Framework\v3.0\Windows Communication Foundation” directory to register the script maps

To quote MSDN:

Registers this version of WCF and update scriptmaps at the Internet Information Services (IIS) metabase root and for all scriptmaps under the root. Existing scriptmaps of lower versions are upgraded to this version.

Installing: Machine.config Section Groups and Handlers (WOW64)
Installing: Machine.config Section Groups and Handlers
Installing: System.Web Build Provider (WOW64)
Installing: System.Web Compilation Assemblies (WOW64)
Installing: HTTP Handlers (WOW64)
Installing: HTTP Modules (WOW64)
Installing: System.Web Build Provider
Installing: System.Web Compilation Assemblies
Installing: HTTP Handlers
Installing: HTTP Modules
Installing: Protocol node for protocol net.tcp (WOW64)
Installing: TransportConfiguration node for protocol net.tcp (WOW64)
Installing: ListenerAdapter node for protocol net.tcp
Installing: Protocol node for protocol net.tcp
Installing: TransportConfiguration node for protocol net.tcp
Installing: Protocol node for protocol net.pipe (WOW64)
Installing: TransportConfiguration node for protocol net.pipe (WOW64)
Installing: ListenerAdapter node for protocol net.pipe
Installing: Protocol node for protocol net.pipe
Installing: TransportConfiguration node for protocol net.pipe
Installing: Protocol node for protocol net.msmq (WOW64)
Installing: TransportConfiguration node for protocol net.msmq (WOW64)
Installing: ListenerAdapter node for protocol net.msmq
Installing: Protocol node for protocol net.msmq
Installing: TransportConfiguration node for protocol net.msmq
Installing: Protocol node for protocol msmq.formatname (WOW64)
Installing: TransportConfiguration node for protocol msmq.formatname (WOW64)
Installing: ListenerAdapter node for protocol msmq.formatname
Installing: Protocol node for protocol msmq.formatname
Installing: TransportConfiguration node for protocol msmq.formatname
Installing: HTTP Modules (WAS)
Installing: HTTP Handlers (WAS)

DPM2010–Exchange VSS backup error 0x800423F4

Sorting out DPM2010 backups of an Exchange 2003 server, and got an error:

The VSS application writer or the VSS provider is in a bad state. Either it was already in a bad state or it entered a bad state during the current operation. (ID 30111 Details: VssError:The writer experienced a non-transient error.  If the backup process is retried,
the error is likely to reoccur.
(0x800423F4))

I had a look at the VSS writer status on that server, and noticed this:

Writer name: ‘Microsoft Exchange Writer’
Writer Id: {76fe1ac4-15f7-4bcd-987e-8e1acb462fb7}
Writer Instance Id: {dc79ccf4-f2a3-4031-9d1e-c59fc2f0a322}
State: [7] Failed
Last error: Non-retryable error

The Application event log had errors which didn’t explain much by themselves (Error code 0×80040102 when preparing for backup. ), but the data within the error log helped me sort out what the problem was:

Incr/Diff snaps not supported with Circular logging enabled.

I then remembered that we’d enabled circular logging on that server in the past because it was backed up using Symantec BESR.

I ended up restarting the Information Store, and then retrying the recovery point. All is well. There’s more information here about the various DPM Hyper-V related issues.

Resolving Shoretel Call Manager’s Outlook integration UAC issues

greenshot_2011-03-01_14-16-49In my previous post, I detailed the issues we’d been having with Shoretel’s Call Manager client under Vista since v8.1 was released. In this post, I’m going to detail the process used to get around the issue until Shoretel resolve it and release an update.

You’ll need to download and install the Microsoft Application Compatibility Toolkit (v5.6 at the time of writing)

The first thing to do is to create the security database containing the Application Compatibility shim (more about this in my previous post). The shim will force the installer to inherit the parent process’ token. When logged on as a standard user, this means that the Outlook integration installer will run as a standard user.

“The RunAsInvoker compatibility fix enables an application to start by using the token inherited from the parent process. The RunAsInvoker fix overrules both installer detection and manifest processing, and will determine the elevation state for the entire application after it is applied.” – TechNet

  1. Fire up Compatibility Administrator
  2. Either create a new custom database, or rename the default one.
    greenshot_2011-03-01_14-23-49
  3. Right-click on the database and select Create New, Application Fix
  4. On the next screen, specify a program and vendor name, and point the wizard to the location of the UninstWrpr.exe file. Hit Next
    greenshot_2011-03-01_14-26-38
  5. On the compatibility mode selection screen, select the “RunAsInvoker” mode, then hit Next
    greenshot_2011-03-01_14-27-59
  6. Don’t select anything on the Compatibility Fixes screen. Hit Next
  7. The next screen will prompt you to choose which identifying information to use to determine when to apply the shim to the target application. It’s probably safest to leave this at defaults. When I first tested the process, I selected only options that weren’t going to change with a new version of PCM, but this may cause issues down the track depending on how you roll out the security database
    greenshot_2011-03-01_14-32-48
  8. The AppCompat database is now almost ready to go. greenshot_2011-03-01_14-35-31
  9. Save the AppCompat database file to somewhere on your network. \\domain\netlogon or in one of your Group Policy script folders would be a good candidate.
  10. Install the patch locally, and have a look in %windir%\AppPatch\Custom. You should see a new SDB file in the form of {guid}.sdb. You’ll need that full file name and path for the batch file below.
  11. Set up a new computer logon script with the following contents:
    @echo off
    @echo Shoretel Call Manager Outlook Integration Patch
    
    if exist %windir%\AppPatch\Custom\{your-patch-guid-here}.sdb goto ALREADYINSTALLED
    
    :INSTALL
    sdbinst -q "\\domain\netlogon\ShoretelOutlookFix.sdb"
    goto END
    
    :ALREADYINSTALLED
    @echo Patch is already installed
    
    :END
  12. Reboot a machine (hopefully a test PC) that has the group policy applied. The computer logon script should run and install the patch. You can verify by checking the %windir%\AppPatch folder to see if the SDB file has appeared.

    If you check in the Call Manager install folder, you will also notice that the UAC shield icon has disappeared from the program icon for UninstWrpr.exe

    UACbefore-after

I’ve tested this, and it seems to work well. Of course, as with anything you find on the ‘net, try at your own risk – and never test it in your live environment.

Unfortunately there’s no other easy way to distribute the SDB file. This shouldn’t hopefully be a long-term fix as we’re still hoping that Shoretel will release a proper solution.

Shoretel Call Manager: Outlook Integration issues

shoretel-productsSince we moved from Shoretel 7.5 –> 8.1, we’ve had a niggling issue that’s about to become a show-stopper on a new deployment for our entire Melbourne office.

The client software is easily deployed via Active Directory and Group Policy, but there’s a problem where the Outlook integration installer requires elevation, even though the only changes that are being made are restricted to the user’s profile. This is obviously ridiculous in a corporate environment, as new user setups require the user to be made a local administrator for their first login just to install Shoretel’s Outlook integration.

I lived with this as an inconvenience over the last few years, but the time has now come to plan for a replacement of our Melbourne office’s out-dated Ericsson PABX system. This issue, then, will be a show-stopper as we’re not going to make 80+ users local administrators – even temporarily.

Last week, I sat down to think about the problem and remembered something I’d read about “shimming” applications in Vista & Windows 7. This then led me to wonder if I could create a shim that stops UAC from being triggered by the Shoretel Outlook integration installer – %programfiles%\Shoreline Communications\ShoreWare Client\UninstWrpr.exe

The above process will obviously break any functionality within UninstWrpr.exe that does actually require elevated privileges, but that’s not a concern to me. I went ahead and created a new Security Database using Microsoft’s Application Compatibility Toolkit, and set up the shim as per one of the technet documents. I installed the resulting sdb file on a test machine using the inbuilt sdbinst.exe command, and voila! The Outlook integration installed without a single UAC prompt, and worked properly to boot.

The only part of the process left, is to figure out how to deploy the shim to the client machines. For the sake of brevity, I’ll detail the entire process in a new post shortly.