Squiggle dot org

I came across a peculiar issue today with Lotus Notes 7, running on my newish Vista system, I was doing some c# development with the Notes COM objects, but was having some trouble, and needed to edit my notes.ini file to try and fix something.

The peculiar part was that in my program files directory, there was a notes.ini file – but with no real config in it, only a few lines – this files usually full of stuff! I also couldn’t see my ID file in the notes data directory when using explorer, but Notes could see it and access it fine!

After a bit of Googling, it turned out it was Vista redirecting application write access to the program files folder to “C:\Users\ %USERNAME% \AppData\Local\VirtualStore’. When the app reads from the program files folder it sees a merged version of the real program files folder and the users VirtualStore, so in essence forces apps to support multi users by the looks of it.

From time to time you’ll come across the problem where a system’s machine account in active directory has either become out of sync (Usually due to multiple systems with the same name) or has just been deleted somehow! Telltale signs of this are errors about domain’s being unavailable, and trust relationships failing whenever the system tries to perform any authentication. In these situations you can usually log in as a local administrator, unjoin/rejoin the domain, then reboot and the problem is sorted.

However, this isn’t so easy if you aren’t in front of the system (which is often the case), although it is possible to do:

First you need to locate the IP address of the system (Names will be unreliable if you’ve got multiple systems with the same name!). The best way to find the IP is probably from looking at DHCP leases on your DHCP server. Once you have the IP address, run regedit.exe on another system, then from the file menu select ‘Connect remote registry’. In the following box, connect to \\<IPaddress>. You should then be able to log on to the system as the local admin user (SYSTEMNAME\Administrator), you should then be able to navigate to:

HKLM\SYSTEM\CurrentControlSet\Control\Terminal Server

In this key, look for the ‘fDenyTSConnection’ value, and set this to 0. This should enable remote desktop if it isn’t already, you’ll need to reboot in order to enable this:

shutdown -m \\<IPAddress> -r

Once the system has rebooted, you should be able to remote desktop to it, log in as the local admin user, and rejoin as if you were in front of it. Although if it was a case of multiple systems with the same name, don’t forget to give it a unique name!

I should also point out that if it was a deleted computer account, you could always restore the object in AD, but that’s another story…

You’ll sometimes have a server that has loads of scheduled tasks that need to run as a specific user account, and sometimes you might need to update the account they run as, or reset the password.

I recently had to change loads of these on our Altiris server, and didn’t really fancy doing it by hand! The following script will update the runas user/password for all scheduled tasks on your system…

@echo off

set Password=password
set Username=DOMAIN\username

cd /d "%SystemRoot%\tasks
for %%a in (*.job) do call :ChangePW %%a
goto :eof

:ChangePW
set TaskName=%*
set TaskName=%TaskName:~0,-4%
SCHTASKS /Change /RU %Username% /RP %password% /TN "%TaskName%"

After bringing a Windows 2003 cluster back online after an unexpected outage today, we had a problem where the file cluster service group wasn’t coming back online, in particular the disk resource (A separate volume on a SAN) was just stuck in the ‘Online Pending’ state, as were all of its dependant resources, and as it was in the pending state you couldn’t take it offline or move it to another cluster node (Not that it would have helped!).

The event log wasn’t too helpful about what the issue might have been, until I came across an entry advising that the volume on the SAN should have ‘chkdsk /f’ run against it. Wondering how you can perform a chkdsk on a volume that the system is having problems mounting it, I turned to google and found the following KB article: How to run the “chkdsk /f” command on a shared cluster disk. The article starts to explain how the chkdsk can be performed, but mentions the following interesting point:

” If the dirty bit was previously set, Chkdsk may automatically run and the Physical Disk resource may take awhile to come online. In Windows NT 4.0, you will see a Command Prompt window with Chkdsk running. In Windows 2000, if you open Task Manager you will see Chkdsk running as a process.”

A quick look in task manager did indeed reveal the chkdsk process running! And the output was being dumped into a file in c:\windows\cluster\chkdsk……. – although not brilliant to read ‘type c:\windows\cluster\chkdsk…’ at the command line made it a bit better to look at! Once the chkdisk had completed (After around 3hrs on our 1.7TB volume!) it came straight online again!

I believe that the chkdsk process could have been killed to quickly bring the volume back online again, but as the dirty but was set, it’s most probable that the same thing will happen next time the disk resource moves nodes.

On alot of systems (especially mobile ones!) it’s often useful to use the ‘Automatically detect settings’ in the Internet Explorer configuration, so that if a proxy is available on the network it will get detected via WPAD, and if there isn’t one, the system connects directly.

I configure this setting on alot of clients using group policy, and it works as you’d expect with IE6. However, after rolling out an upgrade to IE7 to a handful of test systems I noticed that this setting was being ignored, despite it showing on a RSOP for the user/system – although other IE settings such has homepage etc do still continue to be applied to IE7.

Apparently the proxy settings are not being applied because standard users cannot change them after installation. A workaround for this is to set the following GPO:

Computer Configuration\Administrative Templates\Windows Components\Internet Explorer\Make proxy settings per-machine (rather than per-user) = DISABLED

 This needs to be set to disabled – not configured won’t cut it! After setting this ‘gpupdate /force’ might be your friend too!

Failing that, run RSOP.msc on a computer with the issue, and navigate to the ‘Automatic browser configuration’ section in IE maintainance under the user policies, then look under the ‘Auto-cfg detect precedence’ tab, ensure that none of the policies set here are set to disabled.

In previous versions of Windows, we could install the Windows Server 2003 administration/management tools in order to perform administration tasks on remote servers from your workstation. With Vista these tools kind of install, but don’t fully work. Luckily with Vista SP1 Remote server administration tools (RSAT) is now available as a MS download.

RSAT – 32-Bit version (KB941314)
RSAT – 64-Bit version (KB941314)

Once installed, you won’t see anything new on your system… All the installer does is add some new entries in the windows features list. To fully enable them goto ‘Control panel’ > ‘Programs and features’ > ‘Turn windows features on or off’… You should hopefully see an entry in here that you can tick to install them.

I don’t understand why the isntaller doesn’t just automatically turn the feature on if you’re installing it anyway, but it doesn’t bother me that much – it’s not like i’m rolling this out to hundreds of users!

If you’re rolling out Vista to client systems using MS WDS (Windows deployment services) it’s quite useful to ‘inject’ drivers into the image, so that Windows recognises extra devices from the start.

You’ll need the Windows AIK (Automated Installation Kit) installed in order to get the tools required – It’s a free download from Microsoft.

The first thing to do is mount the .wim image. From the start menu, open a Windows PE tools command prompt, then use the following command:

imagex /mountrw "d:\path\to\install.wim" 1 C:\mountDir

This will mount the image into c:\mountDir (You’ll need to have this dir created beforehand remember!). Now that the image is mounted we can inject drivers into it, you’ll need to have the drivers in a directory, and they must contain .inf/.cat files etc. A standalone .exe or .zip won’t work here! Inject them like this:

peimg /inf="d:\path\to\drivers\*.inf" C:\mountDir

This should go through all the inf files in your drivers directory and inject them into the image, now we need to unmount and save the changes to the wim image:

imagex /unmount /commit C:\mountDir

At this point the .wim image is updated with the drivers, and it’s ready to be stuck on a WDS server for deployment to clients!