Here is part 2, the "troubleshooting" section, attached as a .txt document. I suggest you copy and paste the text into WORD instead of trying to print from Notepad; WORD will wrap the txt for you before printing. Again, PLEASE READ the caveats below BEFORE you try these procedures, then use at your own risk: * These instructions are for Win2K PROFESSIONAL, not Win2K server. Please don't ask me questions about Win2K server, I don't know. * These instructions are for a Win2K system created fresh from the Win2K install media, NOT a Win2K system that was upgraded in place from WinNT. (While I'm pretty sure the procedure is similar for an upgraded system, they are different and I haven't tried it yet.) * If you don't follow these instructions EXACTLY, they won't work, exactly. * If you need clarification on my instructions, you can email me directly and I will at least attempt an answer, if I know the answer. Please do NOT send me back replies of the form "I tried this and it didn't work". There are MANY things you can do to make it NOT work, and since I can't see your client machine directories I won't be able to help you. The idea is for other people to use these instructions as a base, figure out how to apply them to other situations, and post THAT information back to the list! * I have used these instructions successfully in testing many times and once for a real bare-metal restore. They have worked at server levels ADSM 3.1.2.42 and TSM 3.7.2 (AIX). Client backups were run from 3.1.0.6, 3.1.0.7, or TSM 3.7.2.01 clients. The bare metal restore was run with the TSM 3.7.2.01 client code; I was unable to get the RESTORE itself to work at any earlier client level. * You should expect to make some changes to customize these procedures for your own system/network. Plan to do a lot of testing BEFORE you need these instructions for real. * These instructions are set up for Win2K Professional machines in a MICROSOFT network, so that when a user boots, he normally logs into the Microsoft domain with a network id. When you see the word DOMAIN in the text, it is referring to the Microsoft WinNT network DOMAIN, not the ADSM/TSM DOMAIN. If your WIn2K Proff machine is not in a network, just ignore all those references in the instructions. If you are in a NOVELL network, you will probably have to modify the instructions somewhat. * You will find these instructions are written in FAR TOO MUCH DETAIL for most TSM administrators! For TSM heavies, you will find they boil down to a list you can scibble on the back of your hand. I know you guys don't need instructions for every mouse click; my target audience was our desktop support staff, some of whom don't get much experience with ADSM/TSM before they get the panic call to rebuild a WIndows machine. * You will see references in the document to something called "adsmreg.bat". This is a .bat file in the user's Win2K startup group that runs the command "dsmc regback user curuser" when the user logs on. This bat file is necessary in SOME environments to insure a backup of the user profile at client levels 3.1.0.6 and below. If you are one of the sites that use it, you know it. If you don't use it, ignore it in the instructions. * There are many references to the "User Profile". In fact, these instructions would boil down to about half a page except that we really want to be sure the User Profile comes back correctly. If at all possible, dig out your Win2K or WinNT book and learn something about user profiles BEFORE you try this at home, it will help you understand what is going on. In general User Profiles are only an issue for WInNT Workstation or Win2K Professional, because the profile retains most of the desktop customization. Profiles exist on Win2K and WinNT servers, but usually nobody cares about restoring them because little customization is done for administrative ids that log on to the Windows server console. I hope this helps somebody as much as you guys have helped me. Wanda Prather "My opinions, and nobody else's...." <<ADSM-L Bare Metal Recovery for Win2K Prof Part 2.txt>>
TSM Bare Metal Recovery for Win2K Professional Part 2: Troubleshooting Problem: When you reboot after restoring the registry, you cannot log in to the network. This problem is usually caused by logging the rebuilt machine on to the network, or in some other way letting the rebuilt machine contact the domain controller, prior to restoring the registry. When the machine contacts the domain controller the first time, the domain controller creates a new password key for it that is stored in the registry. Then after the registry is restored, the key in the registry doesn't match what the domain controller expects to see. Action: Have a Windows administrator remove the machine from the domain, and add it back again. Then you can log on. Problem: After restoring the user profile, you see the default desktop instead of the user's expected desktop customization. This can be caused if you restore the registry, then log off and log on again without rebooting. It will also happen if the ntuser.dat file is missing, or if Win2K for some other reason decides that the user profile is missing or corrupted. Then Win2K creates a totally NEW profile for the same userid. All new profiles start out with the default desktop. You can usually confirm that a new profile has been created by looking at the Documents and Settings directory: * Start Windows Explorer * Expand C: => Documents and Settings * Look for a directory with the same name as the userid, e.g. user23 This is the user's original profile subdirectory. * Now look also for ANOTHER subdirectory with a similar but longer name, for example: userid.networkname userid.000 userid.networkname.000 In Windows Explorer, look at the creation and modified dates for these directories. If they are recent, then Win2K has created a new profile. Action: The easiest way to clean this up is to go into the registry, and change the pointer back to the old profile subdirectory. * Go to Start, Run, regedt32.exe * Click on the window titled HKEY_LOCAL_MACHINE. * Click your way down this path (double-click on the + sign to expand each level): HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\WindowsNT\CurrentVersion\ProfileList * Under the last level, ProfileList, you will see a list of S-id keys, like this: S-1-5-nn-xxxxx-yyyyy-qqqq ONE of them will match the user key that you found in the adsm.sys directory in the section of this document Determine Whether to Restore the User Profile. Click on that key. * Data about that key should appear in the right half of the window. (You may have to select VIEW, VIEW TREE (or KEYS) and DATA from the top menu bar to see the right half of the window.) * You should see "ProfileImagePath" in the right side of the window. Double click on it. * Regedt32 will open a text editor window on the string. Change it to point back to the original profile directory. * Close Regedt32 * Reboot to reload the good pointer to the profile. Alternative: It is also possible (although messy) to be creative with TSM to get the profile data back, even though the profile has moved. You restore the files from: adsm.sys\registry\(machine name)\users\userid to: adsm.sys\registry\(machine name)\users\userid.newprofilename Then you do a selective backup of these files, so they become the "active" backup versions. Then use TSM again to restore just the current user profile, the reboot again. Problem: There isn't a file named S-1-5-nn-xxxxx-yyyyy-qqqq in the adsm.sys directory. Action: Check instead for files with the names starting like the TSM nodename, ex: userx000 userx000.key If you find these files, it means the registry was backed up with the ADSM 3.1.0.6 client code instead of the TSM client code. That's OK. Use the date on these files for comparison with ntuser.dat. HOWEVER, if you determine that you do need to restore the user profile, locate and start the ADSM 3.1.0.6 client icon to do the restore of the user profile, instead of starting the TSM client code. (The 3.1.0.6 code will have come back with the TSM restore of the C: drive and the registry, so the ADSM 3.1.0.6 client should work at this point. The TSM client may not work any longer, because the registry was restored back to a time prior to the installation of TSM.) Problem: There isn't a file named named S-1-5-nn-xxxxx-yyyyy-qqqq in the adsm.sys directory, or files named user000 and user000.key, or these files are very old. Action: If you can't find suitable files in the adsm.sys directory, then the problem is that no backup is being made of the user profile during the registry backup. There was probably a problem with adsmreg.bat process. There is nothing you can do at this point. After you reboot, the user is stuck with whatever customization comes back after the reboot. (It's the customization in the last backup of ntuser.dat, if it was backed up at all, or the default profile, if there was never a backup of ntuser.dat. Report the problem to Desktop Support so they can investigate why no registry backup is running, and hopefully prevent the problem for the next user. Problem: After you restore the registry you get an error that says: "Activation failed for one or more registry keys". Action: If this occurs: * reboot * log on again (still as the local administrator) * if you see the adsmreg.bat window start up and it prompts for the TSM password, do not respond; just shut down the window. * start the TSM client again * restore just the registry again * go back to Determine Whether to Restore the User Profile, P. 4. If the error occurs a second time, please let me know. Problem: These errors and/or prompts occur during the restore of the C: drive: "File is read-only - Force overwrite?" "Error in network path" "Internal Server Error" Action: These remarkably uninformative error messages can occur if the Windows networking id of the newly built disk does not match the Windows networking id of the drive you selected to restore FROM in the TSM RESTORE file tree. Make sure the Windows networking id of the newly built disk is correct, and that it matches the id of the drive you selected to restore. Change the drive networking id BACK to the matching name, if necessary (or you can have a TSM administrator change the drive name on the ADSM server end). Problem: Error on the ADSM restore, "An Active Restore Exists" for blah This occurs when a restore has already been attempted for this ADSM client, but was interrupted. Action: * Start the TSM GUI client. * On the first TSM window, pull down ACTIONS from the menu line. * Select "Restartable Restores". * You should see a line in the window describing the restore that was already in progress. * If this is YOUR restore, and you want to complete it, just click the line of text in the window to highlight it, then click the RESTORE button and the restore will pick up where it left off. * Otherwise, highlight the line of text in the window, then click the DELETE button to terminate this pending restore. Then you can try your restore again. Problem: After rebooting the desktop background is white, with a large-print error message about Active Desktop. Action: 1. Right click on the white desktop. 2. Select "Active Desktop". 3. Select "Customize my desktop" 4. This will pop up the Display Properties window. 5. Click the OK button. 6. Go back and finish the section of this document you were working on prior to the error. The reason is to make sure the TSM client code on the machine to be restored (such as the TSM Central Scheduler and adsmreg.bat) cannot run without prompting you for the password first.
