Resolving “STOP 0x0000007B INACCESSIBLE_BOOT_DEVICE” after you make changes to your hard drive configuration

I’d heard that, unlike previous versions of Windows, a Vista installation could be moved to a new computer without any problems, and would just re-detect all the hardware and reconfigure itself. So when I got my new computer, I imaged my boot partition to the new hard drive (it was much bigger than my old one), attempted to boot Vista, and got this error:

STOP: 0x0000007B (0x818B51B0, 0xC00000010, 0x00000000,0x00000000) INACCESSIBLE_BOOT_DEVICE

WTF? After much digging, it turns out that my new motherboard had AHCI enabled by default, whereas my old one didn’t. This is a SATA standard that supports Native Command Queuing (NCQ), special power management, and some other features. While Vista supports it out of the box, if no AHCI drives are connected when Vista is installed, it disables the drivers, and any attempt to switch to AHCI mode later will give you a blue screen at boot time. The general consensus online is that you have to reinstall Windows, but you do not!

To resolve the error:

    1. In the system BIOS, switch AHCI mode off. This will probably mean something like “Compatibility mode” for the drive – look for a setting that sounds like it does this, either for the controller or the drive itself. This will allow you to boot into Windows again
      1. a.  If you still can’t boot into Windows, you may need to rebuild the boot sector – not as scary as it sounds! Boot the the Vista install DVD, and when prompted, select “Repair installation”. After thinking for about 15 seconds, the install should say that it’s found the problem and corrected it, and you can reboot – Vista should come right up after that.
    2. Once you’re in Windows, load REGEDIT and navigate to [HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\Msahci]
    3. Set the value “Start” to “0”. This will tell Windows to search for AHCI drives when it boots.

Reboot, and switch your hard drive back into AHCI mode when you do. Windows will boot, detect it, and install drivers. It will probably ask you to reboot again

  1. Resolved! Windows boots on your old Vista installation. Aside from this minor hiccup, Vista did indeed cooperate with my new hardware – it detected everything and came right up. It asked me to reactivate, but since it’s a corporate copy, that was no big deal.

Logon Failure: The user has not been granted the requested logon type at this computer

The printer I use to connected to a domain computer, but the computer I print from is not on the domain, so I ran into this ugly error when I tried to map the printer:

Logon Failure: The user has not been granted the requested logon type at this computer

This occurs because the workgroup computer is trying to pre-connect to the domain computer, and since it’s un-authenticated, it connects as “Guest”. Under normal circumstances, the guest account is disabled or, at least, it has been denied rights to connect over the network. Here’s how you remove this restriction:

  1. Download and install the Windows Resource Kit Tools (http://download.microsoft.com/download/8/e/c/8ec3a7d8-05b4-440a-a71e-ca3ee25fe057/rktools.exe). On Vista, you may receive an error that these tools are not compatible, buy you can ignore it – at least in this case, it doesn’t cause any problems, and currently. There’s no new version of the tools available.
  2. From the start menu, click “All Programs” -> “Windows Resource Kit Tools” -> “Command Shell” Run the following commands, in this order (and they’re case sensitive):
    1. net user guest /active:yes
    2. ntrights +r SeNetworkLogonRight -u Guest
    3. ntrights -r SeDenyNetworkLogonRight -u Guest

That’s it! You’ve enabled guest access, so non-domain computers will at least have the ability to connect, though they’ll be restricted to the permissions granted to the local “Guest” account, so you’re not opening up much of a security risk.

Join an Active Directory domain and keep your local profile intact

Recently, I had to join a number of computers in a small office to a domain, but the users all had local profiles that they wanted to keep. Things were a mess – some people’s usernames were the Last name, first initial (the username format I’d chosen for the domain), some were using their full names, and some were using the local administrator account. When I added these computers to the domain, their “domain user” would log in, and would create a new, empty profile. To avoid this took a few extra domain-joining steps, so I wanted to detail them here.

A note: On the computers that were using the local Administrator account as their main login, I had to create a new user and make them a local admin. I just called this user “Transition”, and deleted it once the process was over.

And now for the steps:

  1. Join the computer to your domain, and grant the new domain user local administrator rights before rebooting. Reboot, and log in using the new domain user. This will create a new, empty profile with that user’s domain login.
  2. While still logged in as the new domain user, take ownership of the old, local profile folder. To do this, right-click on the folder, select “Properties”, go to the “Security” tab, click “Advanced”, and then the “Owner” tab. You can set the owner to either the local admins group or the current user – set it to the current user. You must be a local administrator to take ownership (from step 1).
  3. Log out, and log in using either the local administrator account or the transition account you created.
  4. At this point, you can revoke local admin rights from the domain user if they won’t need them. They were only needed to take ownership in step 2.
  5. Open REGEDIT, select the “HKEY_Users” branch, and select “Load Hive…” from the file menu. In the user’s profile folder, there’s a hidden file called “NTUSER.DAT” – that’s the one you want to load. Make sure you’re loading the file from the old profile, not the one that was created in step 1. You can call it whatever you want when you load it – it doesn’t matter. Also, make sure you’ve made a backup of this file before you edit it.
  6. Right-click the user branch you just loaded, and click “Export…”. Export it as a REG file on your desktop.
  7. Open the registry file you just created in either Notepad or Wordpad (I find Wordpad faster for the this step, but it doesn’t really matter). Search for occurrences of “\OLDPROFILEFOLDERNAME\” and replace them with “\NEWPROFILEFOLDERNAME\”. I’ve generally found about 100 references, but it depends on the size of your registry. Also, make sure you convert 8.3 folder names as well – “\OLDPRO~1\” should become “\NEWPRO~1\”!
  8. Save the file after your found/replaced all the occurrences. Double-click the REG file to load it back into your registry (into the user’s hive). You’ll get a warning that not all data was loaded because some keys were in use – that’s fine.
  9. Since not all keys were imported, we’ll need to fix a few folders by hand. Select the user’s hive, and “Find” any occurrences of the old profile path, replacing them with the new path.
  10. With the main user hive folder selected, go to the “File” menu and select “Unload Hive”. The changes are saved automatically, which is why it’s important that you made a backup in step 5. Close REGEDIT.
  11. Rename the domain user’s profile folder to “Username.Empty” (since it’s essentially a blank profile), and rename the user’s local profile to “Username”, which matches the folder name of the profile that was created in step 1.
  12. Log out, and log in as your domain user, enjoying your old profile just as you left it!

This process can be repeated for as many users as you’d like to transition to the new profiles, and you should maintain every one of the settings for your programs. In fact, I’ve never had a program even realize something is afoot, though I’ve only done this on a half-dozen computers.

Please let me know if you have any feedback, and I’d be interested to know of any experiences you have trying this out!

Accessing System.DirectoryServices from SQL Server 2005

SQL Server 2005 allows for the integration of .NET assemblies into the databases so that they can be accessed from inside stored procedures and other database functions. Although this is a great new feature, I got hung up on a particularly cryptic error message when I tried to build an assembly and import it.

Since SQL Server makes it difficult to query active directory, and I wanted to build an AD-based authentication module for my database application, the best way to do that seemed to be to use this new feature. My assembly depended on System.DirectoryServices in order to access Active Directory, but that wouldn’t be a problem, since the .NET 2.0 framework is available from inside SQL Server 2005 (http://msdn2.microsoft.com/en-us/library/ms254506.aspx, provided you’ve enabled the feature), right? Well, sort of. As it turns out, SQL Server was rushed to RTM too quickly for all of the .NET 2.0 assemblies to be cleared as SAFE, so the ones that weren’t fully tested aren’t included by default. Fair enough – so it’s just a matter of importing System.DirectoryServices, and then importing my assembly that relies on it, right? Again, sort of.

System.DirectoryServices can be imported into SQL Server, but only as an UNSAFE assembly. This has all sorts of other security implications (which is a little ironic, since I was using it to verify user security), but I decided to use it anyway, since I figured that the UNSAFE tag was more of a formality than a real danger, and the assembly would be SAFE once more testing had been done. I imported System.DirectoryServices:

USE master
GO

CREATE ASYMMETRIC KEY asmKey_DirectoryServices
FROM EXECUTABLE FILE = 'c:\Windows\Microsoft.NET\Framework\v2.0.50727\System.DirectoryServices.dll'
GO

CREATE LOGIN asmLogin_DirectoryServices
FROM ASYMMETRIC KEY asmKey_DirectoryServices
GO

GRANT unsafe ASSEMBLY TO asmLogin_DirectoryServices
GO

That imports the System.DirectoryServices assembly as UNSAFE. Next, I imported my assembly as SAFE, since it was signed. The only problem was that when I called my assembly, which reached into System.DirectoryServices, I got an error (I’m calling clrIsMemberOfGroup in my assembly, SqlHelper):

Msg 6522, Level 16, State 2, Line 1
A .NET Framework error occurred during execution of user defined routine or aggregate 'clrIsMemberOfGroup':
System.Security.SecurityException: Request for the permission of type 'System.DirectoryServices.DirectoryServicesPermission, System.DirectoryServices, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a' failed.

After 4 hours in the phone troubleshooting the issue with Microsoft, it turned out that it was VERY simple, and even vaguely alluded to in a knowledgebase document. In order to reach into the UNSAFE System.DirectoryServices assembly, I had to make my assembly UNSAFE as well. Since the UNSAFE assembly was running outside the bounds of what .NET considers “SAFE”, it could potentially return suspect results, and so anything that relies directly on those results couldn’t be considered “SAFE”, and had to be tagged as “UNSAFE”. It seems like I should be able to implement proper sanitizing code in my assembly so that I don’t inherently trust the results from my “UNSAFE” assembly, but SQL Server would have none of it. In order to reach into an UNSAFE assembly, I needed to flag my assembly as UNSAFE – simply placing my assembly import into a “Create key, create login, import assembly” setup like the one I used for System.DirectoryServices fixed the problem.

I suppose the question is really “Did that fix anything?” since all I really did was disable security on those assemblies. It’s really hard to throw a security assembly when you don’t do any sort of security checks. Well, at least I alleviated the symptoms, and now I’ll just wait for SP1 to (hopefully) add System.DirectoryServices (among other missing framework assemblies) to the assemblies accessible from inside the CLR access in SQL Server 2005. I suppose we’ll have to wait and see…