ForeFront for Exchange scanners not showing as updated
I recently had one of my Hub Transport servers running ForeFront for Exchange Server 2007 SP1 start behaving strangely. It was reporting that the scanner updates for “Norman Virus Control” and “AhnLab AntiVirus Scan Engine” as being over a week old, even though the most current definitions were on the disk in the correct location and the ini file (update.ini) indicated the correct version both in the ini file and within the ForeFront console. This, of course, caused OpsMgr to send quite a few emails about the out of date definitions.
Trying to force a manual update did no good, neither did restarting the relevant services. The solution, delete the update.ini file and then force a manual update process. You can find the current (extracted) scanner defintion files in the following location:
C:\Program Files (x86)\Microsoft Forefront Security\Exchange Server\Data\Engines\x86\scanner\Bin
Adding 32-bit print drivers to 64-bit print server
This is one of those issues that I just can’t figure out why Microsoft did not include both 32-bit and 64-bit print drivers on the media for Windows Server 2008. Or maybe as a download pack or something. The trend is definitely to use 64-bit servers (no other choice if you’re using Windows Server 2008 R2 or newer), but many client workstations are going to be 32-bit for years to come. Anyhow…if you have a 64-bit print server and need those 32-bit print drivers, see below. (Or vice versa, 32-bit print server serving up print queues to 64-bit workstations).
Step 1: Share a print queue out on the 64-bit print server
- Login with local administrative permissions to the Windows Server 2008 64-bit print server.
- Add a new printer, name it, share it, add to the directory, etc. (You should be using the Print Management Console to manage your printers!)
At this point you have a new shared print queue with 64-bit drivers.
Step 2: Add the 32-bit drivers
- Login with local administrative permissions to a Windows Server 2008 32-bit server. (For best results always use the EXACT SAME OS VERSION AND SP LEVEL here, though you can possibly do this from a fully up to date Windows 7 or Windows Vista workstation)
- Browse to the 64-bit print server by UNC path, i.e. \\PrintServer.
- Click on the Printers folder (or just include that in your UNC path above).
- Right-click a shared printer and select Properties from the context menu.
- Click on the Sharing tab.
- Click the Additional Drivers button.
- Check the x86 Type 3 - User Mode box.
- Click OK, install the drivers.
- Close all open windows.
Done.
Adapted from TechNet social discussion.
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.
-
Translator
