Monday, November 12, 2012

Failing Office automation when run from a service

Scenario: I needed to create a small script to automate the conversion of a Word document into PDF. There's plenty of help out there to script this by using the Microsoft.Office.Interop namespace, for example this simple one. I tried both writing a Powershell script and a compiled C# .exe with the same result: When running from the desktop, everything works fine, whileas running from a scheduled task or from CruiseControl running as a system service failed. If CruiseControl was running from its debug console window however, everything ran fine.

Problem: It seemed clear that the Office libraries required a logged on session to run in, as  also Microsoft confirms here in their Q257757 article.

Solution/workaround: I came across this hack - reposting it here for my own easy access to the knowledge:
  1. Browse to or create this folder: C:\Windows\SysWOW64\config\systemprofile\Desktop on 64 bits Win7/Win2008 - for 32-bits Windows, substitute SysWOW64 part of the path with System32. You might have to change some permissions to get there and you of course need to have administrative rights.
  2. Make sure the user credentials running the service or scheduled task you want to use has full control access permissions to the folder.
I have no idea how this trick can make it all work, but it does - at least in my case. Since Microsoft does not recommend or describe it however - use solely at your own risk. Not suitable for rocket launchers, weapon systems etc..

Friday, June 8, 2012

"Could not find a part of the path" from MSBuild/CruiseControl.NET

This case turned out to be a no-brainer, but for my own (and others who may need it) later reference, here it is:
Scenario: I had set up a test environment for testing MSBuild targets run from CruiseControl.NET. The target I wanted to run was supposed to do simple file operations like copying and unzipping files to a specific disk letter, which in my test environment happened to be a subst to a folder on my local hard drive. Windows 7 64-bits with UAC (User Account Control) on was used, running CruiseControl.NET elevated to give it necessary privileges.
Problem: When running the MSBuild target itself, things worked like a dream. However, when running the target from CruiseControl.NET, it always grinded to a halt at the first attempt to copy/unzip data to my disk
Cause: This is the no-brainer: Since CruiseControl.NET ran with elevated privileges (i.e. started with "run as an administrator"), it did not see the substed drive I had set up from a non-elevated cmd window.
Solution: Simply start a cmd window elevated (run as administrator) and do the same subst from there, and voilla! - it works.

Sunday, March 4, 2012

SyncBack hang/freeze on Windows 7 - SMB version problem

Problem: SyncBack Free is a brilliant free tool for synchronizing two folders' contents fast and accurate. I had been using a Windows XP computer with two network cards standing as a bridge between two networks to sync folders between two computers residing on each side of the bridge. Old of age the XP computer were looking forward to its retirement as a young Win7 computer were set up to take over its place. The same SyncBack running the same SyncBack profile on the Win7 computer completely hung the SyncBack process within seconds after syncing was attempted. Only a reboot would kill the process - not even Task Manager managed to take it down.

Factors in the picture:
  • The two remote computers were running Win7  and Server 2008 R2.
  • Syncing between a local folder on the Win7 computer and one of the remote computers would work. Just not syncing between the two remote computers.
  • It made no difference whether Windows Shell (on the Copy/Delete tab) was used to sync or not.
  • Copying files between the remote computers from Windows explorer works just fine.
Problem reason: The reason proved to be SMB version. WinXP uses SMB 1.0, whileas Win7 uses SMB 2.0. For some reason, SyncBack does not manage to copy files between two remote computers as long as the computer is set up to use SMB 2.0.

Solution: Disable SMB v. 2.0, forcing the Win7 computer to revert to using SMB 1.0. This excellent article on Petri explains how - or here in short: From an administrative command line window run the following commands and then reboot to activate (Observe that "bowser" is actually correctly spelled - or rather, it is spelled the way that the computer understands):
sc config lanmanworkstation depend= bowser/mrxsmb10/nsi
sc config mrxsmb20 start= disabled
If you need to revert to SMB 2.0, use the following commands:
sc config lanmanworkstation depend= bowser/mrxsmb10/mrxsmb20/nsi
sc config mrxsmb20 start= auto 
I have not put any effort into researching whether security is an issue with these settings or whether other functionality is negatively affected, for me it gave me what I needed, so I am happy.