If you had a utility that made use of the /console switch in remote Desktop Connection, and this utility made things a lot easier for you, then maybe you were kind of irritated when MS decided to change the switch to /admin in the latest version of Remote Desktop Connection.

Of course, this is a transitory problem. Eventually, since they aren’t allowing access to Session 0 in Windows 2008, this will cease to be relevant. That will happen when there aren’t any servers out there still running Windows 2003.

Of course, since there are in fact still servers out there running Windows NT 4.0, you might not want to hold your breath about that, and you might want to use the /console switch in the meantime.

Well, I think I found a way to do that.

I fired up a brand new Windows XP SP2 OS, and before upgrading to SP3, I grabbed a copy of these files:
c:\windows\help\mstsc.chm
c:\windows\system32\mstsc.exe
c:\windows\system32\mstscax.dll
These files can also be found in the $NtServicePackUninstall$ folder.

After installing SP3, I renamed these files, and replaced them with the older versions.

Maybe there is a good reason to keep the new ones. Maybe I am missing some awesomeness that I have yet to recognize in the new version of Remote Desktop Connection, and this is a mistake. That’s a risk I am willing to take.

It is also possible that these files will keep getting replaced every time a round of MS Updates comes out, and this will become too much trouble to keep up. For now, it seems to be working, and once again of my favorite tools has one of its most useful features back.

Tags: /console switch, Remote Desktop Connection

Situation: You are writing or debugging some web code, and the error you are seeing in the browser is almost, but not quite, entirely useless. It may be pretty though.

Environment: IE6 or 7 on the workstation, Windows Server 2008 and IIS7 on the server.

The first place to look is the browser settings.

1. Click the Tools menu (might have to press ALT first to see it).
2. Click Internet Options.
3. Go to the Advanced tab.
4. Uncheck the box for “Show friendly HTTP error messages”.

The second place to look is in the Error Pages section of IIS:

1. Open IIS Admin.
2. Select a web site.
3. Open the Error Pages tombstone (doesn’t it look like a graveyard of icons?).
4. Click the extremely intuitive Edit Feature Settings link under Actions on the right side.
5. In the Error Responses area, choose your preference.

It is “more secure” to leave the default settings. One argues that you can do your testing with the web browser on the local server, so you only need local requests to return useful error messages. However, you might wonder during your testing whether IE Enhanced Security, UAC, DEP, and other wonderful security settings that you have left on your server are interfering with the operation of your web application. For this reason, you may want to flip this over to “Detailed errors”, at least while you are working on the problem.

Finally, there is one more place to look.
I am uncertain whether this affects only classic ASP code, or ASP.NET as well, but here it is:

1. Select a web site.
2. Double-click the ASP tombstone.
3. Click the “+” sign next to Debugging Properties.
4. Change the “Send Errors to Browser” parameter to “True”.

That should do the trick. See how much easier debugging is now?

Tags: Debugging, Friendly HTTP Errors, IIS7

Who the heck runs Windows XP on ESXi anyway? I suppose someone with an excess of Windows XP licenses who doesn’t want to buy TS CALs might do it. Someone with RDP-enabled thin clients might do it as well.

Anyway, I was about to kill the XP workstation VM I used to test my trial run of the SBS 2003 to SBS 2008 migration, and decided to try out this ASR thing. I ran a backup, including ASR. I stored the BKF file on a remote workstation share, and stored the ASR file on a virtual floppy.

Then I created a new VM with appropriate disk, ram, and CPU settings, and attached the virtual floppy image to it. I also inserted the VMware SCSI drivers for Bus Logic into that virtual floppy image. Next, I attached a Windows XP ISO image to the VM, and set it to boot into the BIOS at first boot.

Booted it, fixed the time, set the boot sequence, rebooted.

During boot, I pressed F6 to specify hardware drivers, and pressed F2 to tell it I was doing an ASR operation.

I gave it the VMware hard disk controller drivers, it formatted the hard disk, and we moved on.

About the time I was starting to wonder when this was going to stop being a normal Windows OS load followed by a restore, and start being ASR, some unfamiliar windows came up. The first thing it did was c0mplain about not being able to find the backup at the UNC path listed in the ASR.SIF file. I tried to work around that but quickly came to the realization that either there were no network drivers, or Windows Setup was not allowing me to do any networking at that time.

So what next? How do I get the BKF file to where it can be seen? What would MS be expecting people to do with a physical machine at this point? I suppose it would either be a USB disk (which won’t work in ESXi), or a locally attached hard disk. So, I got creative with VMDK files. I loaded up an extra virtual hard disk on another VM, copied the BKF file to it, shut down that VM, and attached the virtual disk to the XP VM I was trying to restore. Didn’t see it, so I rebooted with it attached. It resumed the ASR process, but once again could not see the second hard disk. The only drives it would see were the C drive and the CD drive.

What finally worked was starting over with a larger VMDK, then shutting down the VM at the first reboot, attaching it to another VM that had a Bus Logic controller, and copying the BKF file to the drive that would become C during the ASR boot.

That done, I fired up the VM with the ASR process running, found the BKF on the C drive, and finished the restore. When done, it booted fine, logged in with cached credentials (the SBS2008 server was undergoing another restore at the time), opened the OST file just fine, and did not require re-activation, even though the disk (and its size) was different.

Since most Server VMs are made using the LSI Logic controller, it means having another XP VM handy to do this trick – or building one from scratch and then using it. Is it worth it to build one from scratch and then go through the ASR restore for the other? I’m not sure, having never done a restore using ASR on a fully loaded XP.

Anyway, it was an interesting experiment.

Tags: ASR, backup, ESXi, Windows XP

I just spent some time wrestling with an HP Color Laserjet 2600N printer on SBS2008.
The workstation was XP Pro SP2 x32.
The driver was for Vista x64, downloaded from HP (closest I could get).

The symptom: The driver loaded fine on the server and workstation. Server could print OK. When workstation printed, the job would stick in the queue and not go to the printer, and could not be deleted except by stopping the spooler and deleting the files from the spooler folder. When I restarted the print spooler service without deleting the files, the job would then go to the printer.

The solution: Disable bi-directional support in the printer driver on the server.

Tags: Laserjet 2600N, Print Spooler, SBS 2008

I’m replacing my wife’s computer. There is a flatbed scanner attached which I use for documents that are too big for the sheetfed scanner on my own computer, documents that are bound to something, or when I want a higher quality image than the sheetfed scanner can deliver.

I decided to go ahead and give her the computer with Vista on it, because the way she uses the computer, she won’t really notice the Vista pain I feel.

Unfortunately, the flatbed scanner is an older model, for which there is no Vista driver support. The scanner is “end of life” after a few years.

After much grumbling, I bought a shiny new scanner that looks nearly identical to the old one. I decided (here goes my masochistic streak) to try installing it as a normal, non-administrative user would. I logged on with the wife’s user account and put the CD in the drive.

Thus begins my tale of woe.

Naturally, I get the UAC pop-up, and I allow it. After a couple of other prompts and an install wizard, it finishes. So far, so good. I stuffed an empty Cheetos bag onto the glass and pushed the one-touch scan button. To my amazement, the one-touch software fired right up and started scanning. It finished, then dutifully started opening the Paperport software to store the image.

Bam! Error #1. the SimpleSearch Indexer has stopped working. Problem Details: Appcrash in ssindexr.exe.
A few seconds later: Bam Bam! Error #1. The PDF Import Filter also crashed.

The Paperport Desktop opened and was completely empty.

Another try, then. I uninstalled the thing, emptied the Temp folder, deleted the Paperport folder from Program Files, and made the user account a local administrator. Also, I browsed the CD, right-clicked the setup.exe, and told it to run as administrator. Same process, same result.

OK, I figured I’d give Tech Support a bit of a hassle and call them up. They painstakingly wrote down every error and version number, and then had nothing useful to say. They wanted to put me on hold to “check my resources”. I asked if they’d like me to uninstall the program, empty the Temp folder, disable User Account Control, reboot, and try again while I was on hold. Affirmative. I should leave the scanner driver (one-touch) in there, but do the rest.

So right about the time they came back on the line, I was logging in again. I stopped to talk to them about the issue. No, there aren’t any “known issues” specific to my errors, but yes, they usually do recommend that people turn off UAC before installing (the software has no pop-ups and the docs say nothing to this effect). I should go ahead and try it again, and it should work this time.

I did. It didn’t.

I wished them good day and hung up, sensing that I had gotten as much useful information from them as I was likely to.

I cleaned it all up again, set the local administrator password, enabled the local administrator account, rebooted and logged in as Administrator, and ran through the setup again. This time the Paperport software opened without error (yay!) but the one-touch software was no longer linked into Paperport. I had to uninstall and reinstall it as well.

Finally, I was able to push that button and get a perfect scan of my Cheetos bag.

OK, time for a user profile swap! I reset my wife’s user account to a power user, turned UAC back on, rebooted, logged in as her, and the Paperport software started without error. Of course the one-touch software had lost its link with Paperport. To get THAT back, I had to uninstall one-touch and reinstall it. Then it had the link, but when I pushed the button on the scanner nothing happened. I removed the scanner from Device Manager and scanned for new hardware, which was found and installed. Then the scanner button worked, it scanned, and it even opened Paperport and delivered  - but it did NOT deliver the scanned image into the Paperport desktop.

Sigh.

I finally got this to work by setting the user account as an admin again, turning UAC off, logging in as the user account that would be using the scanner, and using the “RUNAS” command to fire up a privileged CMD instance, then changing directory to the CD drive and executing cdstart32.exe from the CMD window.

At long last, I got my Cheetos bag scanned in, while logged in as the proper user! Sing praises!

Oops, wait a second, the destination was a local My Documents folder. I couldn’t select the network drive to store the documents in during setup, because while using RUNAS, it used the local administrator account, which does not have the drive letter mapped. So I opened Paperport and used the Folder Manager to add the right one. Doesn’t work.

Sigh.

Time to log in as Administrator, map the drive letter, log back in as the user, use the RUNAS command again (Will I have to turn off UAC and reboot? Probably), uninstall and reinstall this damned thing again.

How is the average user supposed to do this? I suspect they tested this exactly one way: On a standalone PC, with UAC disabled, as a local administrator account.

I guess it’s my fault for not buying the $499 network-friendly model, right? As if its installation would not have the same issues.

Well, I won’t bore you with the rest of my battle. I’ll get there eventually.

Cheers!

Update: The software has a particular quirk. It REQUIRES that the local My Documents folder is part of the PaperPort Folders lineup in order for it to scan things into PaperPort. To clarify, I reinstalled it, and it would scan things into PaperPort, but put them in the [MyDocuments]->OneTouch Docs folder. I found the registry key for that destination end edited it, and then it would put things into the mapped network drive just fine. Then I removed the local MyDocuments from the PaperPort Folder Manager, and even though the software was set to place things in the mapped network drive, scanning to PaperPort broke.

It seems that it is not actually necessary to use the RUNAS command to install the software. At least, not after you’ve uninstalled and reinstalled eight or nine times – maybe the stuff that needs that level of security stayed in there after the first time. We all believe that their uninstaller cleans out everything it put in there, 100%, right?

Anyway, another uninstall/reinstall got back the ability to scan to a PaperPort folder, then another registry hack to make it scan to the folder I wanted it to go to, instead of the default (there was no place in the UI to set this). So I’m just going to shrink up the local documents folder tree and pretend it does not exist.

So the path to success goes like this:

1. Cut off your security at the knees by setting your user account as a local administrator and disabling UAC.
2. Install the software, leaving everything at default. It gives you the option to change the initial desktop folder during installation – don’t do it! It will break the Scan to Paperport feature.
3. Hack the registry to make the change that should totally have been included in the UI. The keys to alter are:
[HKEY_CURRENT_USER\Software\Visioneer\OneTouch 4.0\LinkManager 4.0\ScanSoft Applications]
“DefaultFolder”=”X:\YourPaperportDesktop”
[HKEY_CURRENT_USER\Software\Visioneer Backup\LinkManager 4.0\ScanSoft Applications]
“DefaultFolder”=”X:\YourPaperportDesktop”
4. Add that folder to your PaperPort Folder Manager and set it as default, but DON’T remove the local one.
5. Set your security back up the way you want it and test that it still works.

Tags: lua, One-Touch, Paperport, UAC, Visioneer