Black login screen on Windows Server 2003
This was passed to me by Robert C.
Issue: An application server ran out of disk space on the “C” volume. We could connect to file shares but RDP sessions and the console session showed a black screen so no one could not log in.
Fix: Since the server ran out of disk space the colors for the default user are all reset to black. To correct the issue I took a similar OS and exported the following reg key “HKEY_USERS\.DEFAULT\Control Panel\Colors”. Since I could not login, I connected via network registry, saw all of the color values were set to “0” and imported the export from a valid source taken previously. Rebooted and issue was resolved. Below is an example of that that hive should look like.
[HKEY_USERS\.DEFAULT\Control Panel\Colors]
“ActiveBorder”=”212 208 200″
“ActiveTitle”=”10 36 106″
“AppWorkSpace”=”128 128 128″
“Background”=”58 110 165″
“ButtonAlternateFace”=”180 180 180″
“ButtonDkShadow”=”64 64 64″
“ButtonFace”=”212 208 200″
“ButtonHilight”=”255 255 255″
“ButtonLight”=”212 208 200″
“ButtonShadow”=”128 128 128″
“ButtonText”=”0 0 0″
“GradientActiveTitle”=”166 202 240″
“GradientInactiveTitle”=”192 192 192″
“GrayText”=”128 128 128″
“Hilight”=”10 36 106″
“HilightText”=”255 255 255″
“HotTrackingColor”=”0 0 255″
“InactiveBorder”=”212 208 200″
“InactiveTitle”=”128 128 128″
“InactiveTitleText”=”212 208 200″
“InfoText”=”0 0 0″
“InfoWindow”=”255 255 225″
“Menu”=”212 208 200″
“MenuText”=”0 0 0″
“Scrollbar”=”212 208 200″
“TitleText”=”255 255 255″
“Window”=”255 255 255″
“WindowFrame”=”0 0 0″
“WindowText”=”0 0 0″
“MenuHilight”=”210 210 255″
“MenuBar”=”212 208 200″
Anyone else run into this one?
DPM agents not functioning on Server 2008 DCs
I recently rebuilt two domain controllers in a remote site to be Windows Server 2008 SP2 64-bit. They were previously running Windows Server 2003 SP2 R2 64-bit and were in DPM 2007 SP1 with no issues. The build for the 2008 installation from bare metal: the old DCs were demoted, kicked out of the domain and then rebuilt as new with 2008.
When trying to install a DPM agent to the new DC installations now, error 337 was received in the DPM console: the agent did install, but the service does not start and the agent is in an error condition in the DPM console. Looking at a relevant DCOM article in TechNet to verify security for error 337 provided no help. Attempting to manually install and register the DPM agents resulted in the same error. Either way, not good…no protection groups can be configured and no backups can occur.
I could find no documentation specific to what might need to be done to get this working.
Here’s the solution as provided by PSS (with minor edits by me):
*** Problem Description ***
In a 2003 domain that is upgraded to a 2008 domain (native mode) DPM agents on the 2008 domain controllers will never communicate to the DPM server. The agent in DPM will show a red x on it. You can remove the agent and then reinstall the agent with the same results.*** Resolution ***
DPM requires access to AD keys that only have the Builtin “Users” with permissions on them. During the upgrade of the domain, it removes the NT Authority “Authenticated Users” group from the Builtin “Users” group and thus breaks the DPM server from getting access to these keys. To fix this problem, add the NT Authority “Authenticated Users” group to the Builtin “Users” group in Active Directory Users and Computers and wait for replication to occur (in the event of DPM in a remote site), refresh the DPM agent information in the DPM console and you should be green and good.
Strange.
Data Protection Manager 2007 error ID 998
I’m currently doing some testing with Exchange Server 2007 and Data Protection Manager 2007 on Hyper-V. As I needed several VMs for the testing, I just installed one and then used NewSID to change the VM SID and name before joining each one to my test domain. Later, upon attempting to configure a new protection group on DPM for one of the Exchange servers I got this error:
The operation failed because of a protection agent failure.
Retry the operation.
ID: 998
Details: Unknown error (0×80042318) (0×80042318)
After checking the usual suspects, including the required VSS patch on the Exchange server to be protected and examining the Event Logs on the Exchange Server I found lots of VSS errors with Event ID 12302 on the Exchange server.
Tt turns out the problem is actually with using NewSID…it doesn’t play well with VSS. The solution’s pretty simple once you find it–here’s one place it resides. The steps are as follows:
- Stop the Microsoft Shadow Copy Provider & Volume Shadow Copy Service.
- Export the contents of the HKLM\Software\Microsoft\EventSystem key to a .reg file (as a backup).
- Delete the HKLM\Software\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions key. (Just delete the Subscriptions subkey; leave the EventClasses key.)
- Restart the server.
- Run the “VSSADMIN LIST WRITERS” command, which should procude output similar to that shown below.
This causes the VSS entries in the HKLM\Software\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions key to be rebuilt when the writers initialize.
If that does not resolve the problem, check the Sysinternals forum link mentioned above for more steps.
Protecting Exchange with Data Protection Manager 2007
There’s a small (though important) typo in the TechNet article Protected Computer Software Prerequisites in regards to the required steps to protect Exchange Sever 2007 (or Exchange Server 2003) databases.
To properly protect Exchange Server data, you’ll need to have the current version of the eseutil.exe and ese.dll files available to the DPM server. This article proposes to do that via a file system hardlink, although the file paths listed are incorrect. If you go this route (versus manually copying the files into the DPM bin directory), you’ll want to use the correct paths.
Incorrect (as specified in the article):
fsutil hardlink create “c:\program files\microsoft\dpm\bin\eseutil.exe” “c:\program files\microsoft\Exchange\bin\eseutil.exe”
Correct:
fsutil hardlink create “C:\Program Files\Microsoft DPM\DPM\bin\eseutil.exe” “C:\Program Files\Microsoft\Exchange Server\Bin\eseutil.exe”
Oddly enough, the TechNet article does not address the ese.dll file, which is also required. Use this command to hardlink it.
fsutil hardlink create “C:\Program Files\Microsoft DPM\DPM\bin\ese.dll” “C:\Program Files\Microsoft\Exchange Server\Bin\ese.dll”
Data Protection Manager 2007 error ID 31309
To protect a server using Data Protection Manager 2007, you must install two prerequisite software items:
- The DPM agent (see my previous post about the Visual C++ 2008 Redistributable cleanup issue), and
- The VSS hotfix from MS KB 940349
If you attempt to protect data on a server immediately after it reboots following the hotfix installation, you may get an error message with ID 31309 stating that you must install the required prerequisite software…which of course, you’ve already done. Fortunately, the fix to this annoyance is the same as for error ID 31008 as discussed in MS KB 947470. The issue is that the agents don’t update the DPM server immediately. The updates occur approximately every 20 - 30 minutes.
Just complete these steps and you should be on way to protecting that server:
- Start the Data Protection Manager 2007 Administrator Console, and then click the Management tab.
- Click the Agents tab, and then click Refresh information in the Action pane.
- Verify that OK appears in the Agent Status column for each protected server.
- Click the Protection tab, and then follow these steps:
- Create a new protection group, or modify an existing protection group.
- Select a data source.
- Verify that you can add a data source to the protection group successfully.
MOCS 2007 “[0x80004002] No such interface supported”
While trying to assist in the new installation of Microsoft Office Communications Server 2007, I ran into this rather unhelpful error in the error logs: [0x80004002] No such interface supported. I had full Enterprise Admin permissions so that ruled out the typical permissions suspects. What I found solved the error was not trying to use complex passwords when the Setup routine asked for service account passwords. So, if you run into this error during your MOCS 2007 setup, perhaps you’re trying to be too safe…now stop using those complex passwords and try something easily guessable like password. I’m not kidding.
-
Translator
