Computer Stuff

This is such a simple thing that nobody would ever consider writing a blog entry or howto about it, right? The thing is though, I frequently see IT support technicians using Windows Explorer, clicking through into the user’s temp folder, highlighting everything and attempting to delete. They are interrupted (and the process aborted) by a message stating that a particular file was in use and could not be deleted, so they de-select that one file, and try again. Some more files are deleted but once again they are interrupted and told that another file couldn’t be deleted. They de-select that file and try again. This can go on for ages..

Here’s how to do it properly.

Go to a command prompt (Start -> Run -> cmd [enter])

At the command prompt type:

cd %tmp%

and press enter. This will change you into the current user’s temp directory.

Then type:

rd /s .

(that’s rd space slash-S space dot)

then press enter. Don’t forget the . at the end. This means “remove the current directory and all subdirectories, including all files.”

What will happen is that the contents of the temp directory and all subdirectories will be removed, but not the temp directory itself, because you are currently working in that directory (via the CD command) and therefore it can’t be deleted.

You’ll receive access denied messages for all in-use files, plus the temp directory itself. That’s fine. Those access denied messages would have been showstoppers if you were using Windows Explorer.

The above is clearing out the current user’s temp directory, which is located within that user’s profile directory (Documents and Settings\username). To clear out the system temp directory, which is located under the Windows directory, type:

cd %windir%\temp

and press enter. This will change you into the Windows temp directory.

Then just like before, type:

rd /s .

All done! You can type “exit” to close the command prompt.

Internet Explorer 7 / 8 appear broken. Error pages such as “Certificate Error” do not display full information, lots of script errors, “more information” gives blank information, can’t click “continue” on certificate error pages (which means you can’t accept a self-signed cert).

Fix: (download subinacl first).

subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=administrators=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=administrators=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=administrators=f
subinacl /subdirectories C:\ /grant=administrators=f
subinacl /subkeyreg HKEY_LOCAL_MACHINE /grant=system=f
subinacl /subkeyreg HKEY_CURRENT_USER /grant=system=f
subinacl /subkeyreg HKEY_CLASSES_ROOT /grant=system=f
subinacl /subdirectories C:\ /grant=system=f

This is the second time I have encountered this now. Both sites were completely unrelated and had different IT admins. In each case, for whatever reason EAS was not working, probably due to SSL problem or IP address restrictions, but in trying to fix the problem, the IT person left the machine with ExchangeVdir set to /exchange-oma, but no such virtual directory in IIS.
To fix, I simply removed the ExchangeVdir registry entry, but according to MS KB article 817379, on SBS 2003 the key should indeed be set, and a virtual directory should exist called exchange-oma. Therefore, it seems that the IT person is doing the re-build of Exchange IIS virtual directories (as per the well known MS KB article where you do the metabase edit), but the re-build does not create the SBS-only non-standard exchange-oma directory. I am guessing that the CEICW recreates the exchange-oma virtual directory, otherwise it must be manually created as per kb817379.

In any case, this is something to look for when EAS does not work. The IIS logfiles show the requests for /exchange-oma, which does not exist.

The key issue here is that in attempting to fix a problem, the IT person compounds the problem with exactly the same symptoms but a totally different cause. They probably then move on and fix the initial cause of the problem, but it still doesn’t work because they just goofed up the ExchangeVdir stuff.

If the machine already has SQL Server or SQL Express on there, the BPS installer will not automatically create an SQL instance. You can either use an existing instance (i.e. tell the installer to create the Blackberry database on the SERVER\SHAREPOINT instance), which may confuse other sysadmins later and result in accidental removal of the Blackberry database, or you can install SQL 2005 Express yourself manually, which is what I do. It’s in the tools folder after you have extracted the BPS archive. Deselect “Hide Advanced Configuration Options” during the SQLEXPR install, and name the instance something useful like “BLACKBERRY”. You do not need User-Instances enabled.

Here’s the quick setup guide that I wrote after watching the videos. The written install guide is rotten. It makes a simple process look so tough:

Add user BPSAdmin, create Exchange mailbox.
Add to group Administrators (if you forget this you’ll know about it later when you’re unable to logon to the server locally as BPSAdmin).

Active Directory Users & Computers -> View -> Advanced Features
Domain Properties -> Security -> Advanced -> Add BPSAdmin -> Apply onto: User Objects -> Send As

Regedit: HKCU->Software->microsoft->Exchange->ExAdmin-> New DWORD ShowSecurityPage=1
Exchange System Manager -> Right-click Org -> Delegate Control -> Next -> Add BPSAdmin -> Exchange View Only Administrator
Right-click Org -> Properties -> Security -> BPSADmin -> Allow Administer IS, Receive As, Send As.

Log off.

Log on as BPSAdmin

Start BPS setup, accept all defaults, enter the BPSAdmin password.

Set up device as usual – Options -> Advanced Options -> Enterprise Activation.
When entering the email address, use space bar instead of @ and dot.

I like this trick. Every time I do it, I think about all those people doing repair installs (in-place upgrades).

It works pretty much every time unless the filesystem is really truly screwed, in which case you need a backup, say from the system restore directory (System Volume Information), as per this knowledgebase article (don’t bother with the recovery console though, use your USB to IDE or USB to SATA cable and fix it from your laptop.)

Here are the symptoms. You try to start up your Windows 2000/XP (Vista too?) computer and you get a message, white text on black background:

Windows could not start because the following file is missing or corrupt: \WINDOWS\SYSTEM32\CONFIG\SYSTEM

or

Windows could not start because the following file is missing or corrupt: \WINDOWS\SYSTEM32\CONFIG\SOFTWARE

Sometimes, the message is cut short, so you might see “\WINDOWS\SYSTEM32\CONFIG\SYS” or similar. Hint: If it’s really cut short, and you can’t see if it’s SOFTWARE or SYSTEM, do the following procedure on both files. Whichever one is identified as having been repaired, well that’s the one that was broken

Anyway, how to fix it in 2 minutes:

Use your USB to IDE/SATA adapter cable, and connect the broken machine’s hard drive to your laptop, or your spare PC or whatever. You don’t have to use a USB to IDE/SATA adapter cable – if you’re a person at home with another PC you can stick the drive on a spare IDE or SATA channel. You just need to get that hard drive into a working Windows XP computer for a few minutes.

Windows will mount the broken computer’s hard drive as, say E: or F:. Make sure you have your computer set to show hidden files and also system files. To check this, go into My Computer -> Tools -> Folder Options, -> View Tab, and select “Show hidden files”, and make sure “Hide protected operating system files” is not ticked.

First things first, run chkdsk on that drive, after all it is most likely filesystem corruption that has caused the registry to become corrupt in the first place. In My Computer, right-click the broken computer’s drive and choose properties. Go to tools, “Check Now”, put a tick in only the first box (Automatically fix filesystem errors), and click start. Let that finish before continuing.

Here’s where the magic happens. Go to start -> run, and type regedit [enter]. This will launch the registry editor on your computer. In the registry editor, highlight HKEY_LOCAL_MACHINE, and then go to File -> Load Hive. Find the file that is “missing or corrupt” (from your error message earlier), and choose to load that. It will be in E:\(or F:\)Windows\System32\Config, and will be called just SOFTWARE or SYSTEM. Regedit will ask you to name the hive, just type “badpc” (any old garbage will do – it’s only temporary).

Regedit will say “One or more files containing the registry were corrupt and had to be recovered by use of log files. The recovery was successful.” You have just repaired the registry! Now you need to Un-load that hive, so highlight that “badpc” hive that you can now see under HKEY_LOCAL_MACHINE, and go to File -> Unload Hive.

You now just need to put that hard drive back in the broken computer, which hopefully won’t be broken any more! If you used a USB to SATA or USB to IDE cable from your laptop, make sure you use the “Safely remove hardware” icon in the system tray next to the clock to safely remove the hard drive, else you may cause filesystem corruption again. Alternatively just shut your laptop/working computer down properly and remove the hard drive once it’s shut down.

All done.

Some background:

The registry is a database. It has transaction log files which can be used to recover from corruption. It would appear that the early Windows boot process is not able to work with those log files, but regedit (and Windows itself further on in the boot process) is.