What tripped me up about this procedure is that I had incorrectly assumed that it was a one-time operation when in fact it must be done each time Hyena is launched. Right-click the domain in question in the tree pane. Select "Set source Domain Controller". If this is your first time, you *may* have to enter the FQDNs of your DCs here. They always show up in my dialog automagically though and I simply click Okay as soon as the dialog pops up. That's all there is to it. Now expand the tree and see all the goodies.
A very good article on how the MBR works can be found here.
Historically, in Microsoft-land, the MBR has been repaired using a DOS boot floppy and the command fdisk. However, the command fdisk is incompatible-with-Windows NT/2000/XP.
In walks "MBR Fix". It's free and it works from Windows NT/2000/XP/2003 command prompt, and so is perfectly suited for use in removable operating systems (ERD Commander, BartPE, WinPE, etc.) You can download it here.
The Microsoft Software Forum Network has a very detailed section entitled Unattended Windows which gives a very good breakdown of how to produce automated Windows OS and application installation, configuration and tweaking.
Keywords: windows software application install installation msi ris automated unattended
...which is why we didn't bother to check it for you by default.
This would have been useful to know for the past couple years:
"If you regularly work with a large number of folder windows at the same time, you can quickly and easily improve the stability of your PC. By default, each folder you open occupies the same area of RAM. This means that Microsoft Windows XP has to do a great deal of shuffling as you flick between windows, potentially leading to crashes. In the Control Panel, double-click Folder Options and move to the View tab. Scroll down the list in the lower portion of the dialogue box and tick ‘Launch folder windows in a separate process'. Click OK."
Taken from Microsoft Windows XP: The Official Magazine - 50 Best Tips Ever.
Explorer can hang for minutes at a time, often taking other applications or your whole system with it. I have now seen this on at least a dozen installations. I have spent many an hour trying to track down what the root of the cause was. Here are some of the many possible causes compiled in a quick list so you don't have to suffer what I've suffered:
After reading the subject line, you are undoubtedly saying to yourself, “…What?” And with good reason I might add.
It turns out that viewing the properties of a Public Folder from the Exchange 2003 ESM (Exchange System Manager) which was created in Exchange 5.5 and migrated to Exchange 2003 will automatically cause the folder to become mail-enabled — even if you “Cancel” out of the properties window and made no changes at all! What’s better? Now you can get cryptic serialized names showing up in your GAL that look like this one I found today (exact copy and paste, no embellishment): 2708b030-d58a-42c0-8764-ff90f8735656. What’s better is the string of phone calls and emails that pour in from executives who are wondering why this is happening and are not only unsympathetic to your plight as an Exchange sys-admin (who lobbied from the get go to never install Exchange in the first place) but are also entirely incapable of comprehending that there is no possible way to remove this known and documented Microsoft Exchange issue.
Ways of updating Backup Exec:
How to ping from a VMS box with UCX installed on it:
ucx ping {hostname|ip}