- Windows Vista
- Windows 7
- Windows Server 2008, 2008 R2
You know that something a bit odd is going on when one of a batch of servers starts throwing errors that the others sailed past. In this case trying to configure PEAR for a new PHP install with Mail, Mail_Mime and Net_SMTP (pear.php.net/mail, pear.php.net/mail_mime and pear.php.net/net_smtp) should be fairly standard. The other servers took the install and even this server too Mail and Mail_Mime but would not accept Net_SMTP returning:
Leaving it overnight before rolling up my sleeves (in case it was just downtime at the package repository) the fix was fairly simple.
If you are experiencing the same problem this server was having, running the following
Will result in
If you get something akin to the above simply browse to:
and delete the pear folder
- Windows Vista
- Windows Server 2008, R2
- Windows 7
Take the hypothetical situation: Windows 7 fails to boot, you don’t want to lose your user data so you install 7 onto a clean partition. However your old user profile is associated with the random SAM ID from the old installation and the new Windows installation cannot mount the profile. You can copy your data files back over, but you really don’t want to configure the start menu settings for the 1,000,000th time.
Or how about: Your only domain controller failed leaving disassociated roaming profiles on a roaming profile share and you want to recover as much of the user settings and data as possible for use on the newly build AD forest. <– That actually happened to Matt, hence I day dreamed this up.
NT user accounts are associated to a Security Account Manager (SAM) ID. The SAM ID is Windows’s SAM or the Active Directory domain user services way of identifying a user, in effect the SAM ID is a super key that identifies a user account on a windows system, acting as a GUID for that profile.
The user name itself is irrelevant and plays no part in identifying the user account apart from being used to performing a reverse lookup to get to the SAM ID, on which Windows bases its logon activities and security token generation in AD.
When you reinstall Windows, the new installation has no awareness of any of the accounts, so if you copy the profiles back into the Windows users directory you will be unable to re-associate that profile with the local SAM database.
The simplest way of restoring user data and crucially environment settings (such as desktop wallpaper, window settings and the like) is to follow this process:
- Create a new user account for the user you want to migrate onto the new domain/installation
- Set the accounts roaming profile settings (if dealing with a roaming profile)
- Logon to the machine with Administrator rights
- Load Regedit
- Click on HKEY_USERS
- From the File menu, select Load Hive…
- Browse to the NTUser.dat from the previous install/roaming profile for the profile that you are trying to recover and click OK e.g.
- When prompted for a name just enter temp and click OK
- Expand and click on:
- From File select export and save the export file as:
- From File, select Unload Hive…
- Exit Regedit
- Open c:\temp.reg
- From the Edit menu select Replace…
- In Find What: enter:
In Replace With: enter:
Press Replace All
- Save the reg file and exit notepad
- Log off of Administrator
- Log on as the new user
- Double click on c:\temp.reg and import the reg file into the new (completely default) user account. If you are using a system with UAC you will need to import the reg file using an administrators account.
- Immediately log off
- Log back in as Administrator
- Go to the recovered profile folder e.g.
- Select all files in the folder apart from NTUser.dat, NTUser.ini and NTUser.dat.log and copy them
- Paste the data into the new user profile e.g.
- The data and the profile settings have now been recovered. Logging back in as the recovered user will restore much of the user profile and all of their data.
Note: It may be necessary to reset folder permissions and ownership on all of the files pasted into the folder to match that of the new user account.
Thanks to Matt Gillard of MGComputing for some testing of my theory.
- Windows NT 4.0
- Windows 2000
- Windows XP (x86)
- Windows Server 2003 (x86)
- Windows Server 2008 (x86)
- Windows 7 (x86)
- Windows Server 2003 (x64)
- Windows Vista (x64)
- Windows 7 (x64)
- Windows Server 2008 (x64)
- Windows Server 2008 R2 (x64)
- Windows Server 2012 (x64)
When you attempt to connect to a Microsoft Access database using the ODBC provider Microsoft.Jet.OLEDB.4.0 you receive the error message:
For x64 Systems:
The Microsoft.Jet.OLEDB.4.0 is only available as a 32-bit (x86) module. In order to use it via IIS you must change the web site to run in a 32-bit application pool.
Under IIS 7.0, 7.5 or 8.0:
- Assuming that you will not want to use ASP .net, in the IIS console in the Application Pools section, create a no managed code, integrated application pool. If you do want to maintain access to ASP .net, select the framework version you require.
- Once created, in its advanced settings set “Enable 32-bit Applications” to true
- In the Basic Settings… for the web site entry you are experiencing the error on, change the Application Pool to the newly created 32-bit pool.
- Restart the web site
In most cases where the system is running under an x64 architecture, this should fix the problem.
For x86 and x64 Systems:
We had a server down for an entire day because of this one. It was either an attempt to fix a security database fault, or an update from Microsoft Update delivered in the April 2008 patch cycle, but after the reboot for the patches, none of the JET (Access) databases on the particular server, in any IIS web would operate.
I will simply cut to the fix for you in the beginning, to expedite your likely finding of a resolution to this problem. Something had caused the service provider for the Microsoft.Jet.OLEDB.4.0 provider to become unregistered. To fix the problem issue the following command from a Command Prompt or Run:
You shouldn’t need to reboot to solve the problem, it didn’t in my case. However, if nothing happens do restart before progressing to the next step.
Additional Steps: Step 1
Reregister the components from MDAC, JET and ADO in their entirety. Simply copy the below into a BAT file and run it.
Additional Steps: Step 2
Reinstall MDAC 2.8 SP1 (Windows XP SP1 or below only). You will need to perform some registry modifications before you can reinstall MDAC as it is a protected system module.
- Open Regedit
- Navigate to:
- Look through each class ID for the following friendly name values. Delete the Class ID containing the matching friendly names:
Microsoft MDAC Response Files
Microsoft MDAC Setup Files
Microsoft SQL Server ODBC Drivers
Microsoft SQL Server Net Libs
Microsoft SQL Server OLEDB Provider
WebData Setup Exception Package
Mdac 2.8 Exception Package
- Download and reinstall MDAC 2.8 SP1 from Microsoft which should reinstall in full.