To properly set the DSConfigDN attribute on the Standalone CA:

1. From an administrative command prompt, enter the following command to set the Configuration container DN for the Root CA. 
   certutil -setreg ca\DSConfigDN “CN=Configuration,DC=mycompany,DC=local”
2. You should get the following output back:
   • SYSTEM\CurrentControlSet\Services\CertSvc\Configuration\ROOTCANAME\DSConfigDN:
   • NewValue:  DSConfigDN REG_SZ  = CN=Configuration,DC=mycomapny,DC=local
   • CertUtil -setreg command completed successfully.
   • The CertSvc service may need to be restarted for changes to take effect.
3. Stop and then start the Active Directory Certificate Services service as required.  This can be done from the command prompt, the Services console or the CA console.

The change looks like that seen in the figure below when viewed in the Registry Editor.

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

Step 1:  Share a print queue out on the 64-bit print server

1. Login with local administrative permissions to the Windows Server 2008 64-bit print server.
2. 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

1. 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)
2. Browse to the 64-bit print server by UNC path, i.e. \\PrintServer.
3. Click on the Printers folder (or just include that in your UNC path above).
4. Right-click a shared printer and select Properties from the context menu.
5. Click on the Sharing tab.
6. Click the Additional Drivers button.
7. Check the x86 Type 3 - User Mode box.
8. Click OK, install the drivers.
9. Close all open windows.

Done.

Adapted from TechNet social discussion.

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?

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.

If you answered yes to both of these questions then you’re going to be spending a lot (A LOT) of time working on the writing and approval of a Certification Practice Statement (CPS) and possibly also a Certificate Policy.  Per RFC 3647, there is a specific template should should be followed in most, if not all, cases.

Download a template here and don’t forget to also get your organization a Private Enterprise Number (PEN) from IANA…you’ll want that PEN to create your OID tree and assign a globally unique OID to your CPS.

Disclaimer:  The template is provided with no warranty or guarantee to suitabiltiy in your orgniazation.  The template was created using Microsoft Word 2007 and may open or appear differently in other versions.

Get the template:  Note: There is a file embedded within this post, please visit this post to download the file.

Anyhow, I had been alerted by the applications teams that a certain user that was provisioned within the application security tools hadn’t had a userProxy object created accordingly.  Upon further investigation, I found that the scheduled synchronization process, which relies on an ADAM LDIFDE import to create the new userProxy objects had been failing for several days.  Running the scripted LDIFDE import command manually, so I could see the exact error, yielded the following output:

C:\WINDOWS\ADAM>ldifde -b <account, domain and password> -s <server> -t <port> -i -k -f <import.ldif file>
Connecting to “<server>”
Logging in as “<user>” in domain “<domain>” using SSPI
Importing directory from file “<import.ldif file>”
Loading entries..
Add error on line 7: Unwilling To Perform
The server side error is: 0×20e7 The modification was not permitted for security reasons.
The extended server error is:
000020E7: SvcErr: DSID-03152AA9, problem 5003 (WILL_NOT_PERFORM), data 8471

0 entries modified successfully.
An error has occurred in the program

When looking at the import file, there were no issues noted…nothing out of the normal.

dn: CN=adusers,CN=application,CN=adam,DC=company,DC=local
changetype: add
objectclass: container
objectclass: top
cn: adusers

dn: cn=someuser,CN=adusers,CN=application,CN=adam,DC=company,DC=local
changetype: add
objectSID: S-1-5-21-xxxxxxxxxx-xxxxxxxxxx-xxxxxxxxxx-xxxxx
objectclass: userProxy
cn: someuser

The key part of that error is actually the data field, 8471.  A check of that error code on the System Error Codes (Windows) site of MSDN reveals the following information:

ERROR_DS_NAME_ERROR_NOT_UNIQUE
8471 (0×2117)

Name translation: Input name mapped to more than one output name.

So, a duplicate SID exists (the SID is the unique identifier and I’d already verified that this specific CN did not exist in the “ADUSERS” partition of the ADAM instance.  Now knowing that this userProxy cannot be created due to a duplicate SID problem, things are getting clearer…but how to determine what existing userProxy object has that SID?  And how did another userProxy object get the same SID? 

First things first, to determine what existing userProxy object has that SID already, an export of the ADAM “ADUSERS” partition is required.  Use a command similar to the following to get it:

C:\WINDOWS\ADAM>ldifde -s <server> -t <port> -d CN=adusers,CN=application,
CN=adam,DC=company,DC=local -f e:\output.ldif

Now that you have the ldif file, the next step is to find the Base64 value of the SID for the user account in question.  The easiest way is to look up the objectSID value in ADSIEDIT, targeted at Active Directory (not the ADAM instance) and get the Hexadecimal value of the objectSID attribute for the user account in question.  Then convert that Hex value into Base64 using your favorite converter.  A really nice one can be found here at TRANSLATOR, BINARY.  Simply copy the Hex value into the Hex input box and click Decode.  Your Base64 value appears below.  Copy this Base64 value and use it to search the exported ldif file.  You’ll find the userProxy object with the duplicated SID in no time.

In my case, the problem tracked back to a name change on the user object, changing the first name.  The userProxy object had previously been created for the user account before the name change (and with the same SID obviously), but the application administrators had not deleted the old (incorrect) userProxy object manually as they needed to.  Thus when the LDIFDE import process tried to create a new userProxy object for the newly renamed user account, the import process failed.  Once the incorrect userProxy object was deleted, the import process was able to complete again successfully.

Check out the AD Powershell team’s blog:  Active Directory Powershell Blog (easy enough name to remember) for more information and a downloadable cmdlet reference chart.

Thanks AD Powershell Team!

Update Rollup 7 for Exchange Server 2007 SP1 has been released.  The full list of fixes and updates is documented in MS KB 960384, but I think a lot of people will be happy to see this one specific item corrected:

• 961281- An error is returned when you enable SCR from any source in a child domain after you install Exchange Server 2007 Service Pack 1 Rollup 5

You can get the update here and get to updating!

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:

1. Stop the Microsoft Shadow Copy Provider & Volume Shadow Copy Service.
2. Export the contents of the HKLM\Software\Microsoft\EventSystem key to a .reg file (as a backup).
3. Delete the HKLM\Software\Microsoft\EventSystem\{26c409cc-ae86-11d1-b616-00805fc79216}\Subscriptions key. (Just delete the Subscriptions subkey; leave the EventClasses key.)
4. Restart the server.
5. 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.

Be sure to triple check your entries and TEST IN A LAB ENVIRONMENT before unleashing this production!

Summary: 1 item(s). 0 succeeded, 1 failed.
Elapsed time: 00:00:00

Add-ExchangeAdministrator
Failed

Error:
Active Directory operation failed on dc21.root.local. This error is not retriable. Additional information: The specified user does not exist.
Active directory response: 00000525: NameErr: DSID-031A0F80, problem 2001 (NO_OBJECT), data 0, best match of:
 ”

The object does not exist.

Exchange Management Shell command attempted:
Add-ExchangeAdministrator -Identity ‘company.local/SystemUsers/Service Accounts/ServiceAccount42′ -Role ‘ServerAdmin’ -Scope ‘XHT10A’

Elapsed Time: 00:00:00

Here’s one newsgroup post with this error, I’m sure there are others as well.

There are quite a few discussions going on currently about the effects of UR6, both at the MS Exchange team’s blog and on the TechNet forums.

All I can say, is that so far I’ve seen no issues.  I do make it habit to run the updates using an account with Exchange Organization Administrator privileges though, so that explains away several of the complaints people have made (you’ve got to have that level of access for the scripts to run properly…).

I’ve put the update on 1 HT, 1 CAS and 2 SCR target nodes as well as a DPM 2007 SP1 server.  I’ll be updating an additional 2 HT, 2 CAS and 4 CCR nodes shortly.  So far, I wasn’t asked to perform any reboots and I had no issues.  Yes, the update does take a long time to apply, but that’s been normal for the recent UR packages.  As a general rule, even though a reboot was not requested, I ALWAYS make it a rule to reboot Exchange after applying any Update Rollup or Service Pack…consider that good advice that will go along way towards services that don’t start properly after an update.

Have you had any issues?  I’ll post the results of my next round of updates after I complete them.

Get the UR here and install it as soon as possible.  No mention of whether or not this UR fixes the bug identified with SCR in UR5 or not.

Microsoft Security Bulletin MS09-003 explains the two vulnerabilities in general terms.  Sounds bad, generally speaking.

This security update resolves two privately reported vulnerabilities in Microsoft Exchange Server.

The first vulnerability could allow remote code execution if a specially crafted TNEF message is sent to a Microsoft Exchange Server. An attacker who successfully exploited this vulnerability could take complete control of the affected system with Exchange Server service account privileges.

The second vulnerability could allow denial of service if a specially crafted MAPI command is sent to a Microsoft Exchange Server. An attacker who successfully exploited this vulnerability could cause the Microsoft Exchange System Attendant service and other services that use the EMSMDB32 provider to stop responding.

MS KB 959241 contains the full list of updates and fixes.

Update Rollup 6 for Exchange Server 2007 SP1 fixes the issues that are described in the following Microsoft Knowledge Base articles:

950675:  Downloaded .xls file attachments are empty when you open the files by using Outlook Web Access on Exchange Server 2007 Service Pack 1

955443:  Some free/busy messages are not replicated from Exchange 2007 to Exchange 2003 servers after some mailboxes are migrated from Exchange Server 2003 to Exchange Server 2007

956536:  The Microsoft Exchange File Distribution service uses lots of memory and processor time when Exchange Server 2007 processes many OABs

956624:  The Microsoft Exchange Transport service crashes continuously after you enable journal rule or deploy an antivirus application on an Exchange Server 2007 server

957748:  The custom message class of contact object is overwritten by the normal IPM.Contact class when an Exchange 2007 server replicates the contact object to any other public store

959239:  MS09-003: Vulnerabilities in Microsoft Exchange could allow remote code execution

Uninstalling version 11 and moving back to version 10.2 allows Windows Updates to be performed again, although I’m not sure yet what the real issue is or how to fix it.  Anyone else run across this?

Update 2/20/2009:  This may be the solution, though I’ve not tried it.

Before trying to configure SCR, be sure that your mailbox server has been configured properly first.  That includes installing and configuring the Operating System and storage exactly the same as the SCR source (typically a CCR cluster).  Here’s a few pointers:

• If you use volumes F, G, H, and I for two databases and two storage group logs…make sure you have that configuration on your SCR target. 
• You should size the hardware identically to the SCR source, so use the same CPU type and speed, same amount of RAM, same server model, etc. where possible. 
• Install Exchange using a custom setup and install the stand-alone mailbox server role.
• Leave the default mailbox storage and storage that Exchange setup installs, but be sure to remove the mailbox it created for you (if you were using an account without a mailbox).  You’ll need these local mailboxes for Ops Mgr monitoring and routine testing purposes…just don’t create any real user mailboxes in them!

Here’s the commands you’ll need to run from the Exchange Management Shell to get things rolling:

Run from an Exchange server or management station on the same operating system version (although 32-bit or 64-bit does not matter) that does NOT have Exchange Server 2007 SP1 UR5 installed:

1. Enable-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN-ReplayLagTime x.x:x:x -TruncationLagTime x.x:x:x
   • Be sure to see the cmdlet notes to understand the implications of ReplayLagTime and TruncationLogTime.  The values are in days.hours:minutes:seconds.
   • If you ever need to change the values configured for ReplayLagTime or TruncationLogTime, you’ll have to disable the copy and enable it over again anew.
   • Here’s the issue with UR5.

Run from the SCR target server, after verifying that Active Directory has replicated (especially critical when your SCR target server is located in a different AD Site):

1. Suspend-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
   • This cmdlet is usually not required, but it’s good practice to run.  The SCR copy is configured and in a suspended state following the issuance of the Enable-StorageGroupCopy cmdlet.
2. Update-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
   • This gets the full copy (full reseed) started.
3. Resume-StorageGroupCopy -Identity “SCR_source_server_name\Storage_Group_name” -StandbyMachine SCR_target_server_FQDN
   • This cmdlet is usually not required, but it’s good practice to run.  The SCR copy is resumed following the completion of the reseed.

To check the SCR replication status for all SCR instances on an SCR target server, issue the following command:

• Get-StorageGroupCopyStatus -Identity “SCR_source_server_name\*” -StandbyMachine SCR_target_server_name

TechNet cmdlet references:

• Enable-StorageGroupCopy
• Suspend-StorageGroupCopy
• Update-StorageGroupCopy
• Resume-StorageGroupCopy
• Get-StorageGroupCopyStatus

• MSExchange Replication:  ReplayQueueLength - sustained for 5 minutes - Red(>15)
• MSExchange Replication:  ReplayQueueLength - sustained for 5 minutes - Yellow(>7).

Since the replay queue length is always going to be rather large due to the nature of how SCR operates (this value will never be less than 50 logs and will almost always be more than that), you’ll need to determine what the normal values of the replay queue depth are for your SCR targets.  As an example, I have two SCR targets (from CCR sources) that routinely have replay queue depths of 300 - 400 logs with just a 1 hour ReplayLagTime value configured!  See this TechNet article for more information configuring SCR.

I’d suggest making your “yellow” value at least 100 above your normal average replay queue depth and your “red” value at least 250 - 350 above your normal average.  Make your overrides on the specific mailbox servers that are your SCR targets…not at the global level.

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”

• 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:

1. Start the Data Protection Manager 2007 Administrator Console, and then click the Management tab.
2. Click the Agents tab, and then click Refresh information in the Action pane.
3. Verify that OK appears in the Agent Status column for each protected server.
4. Click the Protection tab, and then follow these steps:
   1. Create a new protection group, or modify an existing protection group.
   2. Select a data source.
   3. Verify that you can add a data source to the protection group successfully.

This is is not a converted version, so installation is easy.  Be sure to remove the previous version if you had it installed.

On the DPM side of things, make sure that you have SP1 or the Feature Pack in KB949779 installed before importing the management pack.  As usual, get your management packs in the Catalog.

This management pack offers end-to-end monitoring of both the DPM servers and clients.

Enable-StorageGroupCopy:  Standby continuous replication is not supported between computers in different Active Directory domains.  The target node is in domain <child.domain.local>, which is different from the source domain <domain.local>.

Tim McMichael has a blog entry about it here that gives you some alternate methods to get SCR configured.  I choose to first run the Enable-StorageGroupCopy cmdlet from a second Exchange mailbox server in the warm site that hadn’t been updated with Update Rollup 5 yet.  Of course, I’ll need that second mailbox server for the remaining storage groups soon enough, so it looks like the option to use another server of the same OS level is the best choice…a VM works as well as anything else.

On a side note, I certainly hope that full support for SCR is included in Exchange Server 2007 SP2…including thge ability to view the SCR instances on the SCR target in the GUI.  It would be nice to be able to activate and deactivate from the GUI as well…or at least something more than what you can do now…which is nothing!

When looking at the queue for delivery to the AD site where the primary Exchange installation is (and where my mailbox is homed at), I noticed it was in a retry state with the following error message:

451 4.4.0 Primary target IP address responded with: “451 5.7.3 Cannot achieve Exchange Server authentication.” Attempted failover to alternate host, but that did not succeed. Either there are no alternate hosts, or delivery failed to all alternate hosts.

So not the most explicit reason for the routing failures, but something at least.  I first thought that perhaps I had somehow changed the settings on the “Default” receive connector on one or both ends of the connection (i.e. the Hub Transport at the DR site and one or more of the Hub Transports at the main site).  On the “Default” receive connectors, you’d want to ensure that you’ve not changed any of the authentication methods on the Authentication tab.  Specifically, Exchange Server authentication and Integrated Windows authentication need to be selected as they are by default.

The settings were as they should have been, but yet routing between AD sites was still stuck.  The problem, as it turns out, was the Cisco ASA 5510 device providing the site-to-site VPN connectivity between the two locations.  It seems there’s a bug in the ASA version 7.1 code base that causes the ESMTP inspection process to remove some information that is not required by the relevant RFCs.  Unfortunately, Exchange Server 2007 requires that information for ESMTP hostname validation.  From the Cisco WIKI article on the bug:

The Extended Simple Mail Transport Protocol (ESMTP) inspect feature masks the hostname and causes an error when a mailserver is configured to ensure the HELO reply is a valid hostname.

So…the solution is fairly simple once you identify the relatively obscure cause…simply turn off ESMTP inspection on the ASA device.  You can do this by following the CLI steps outlined in the WIKI article or by using the ASA GUI (Configuration > Security Policy > Service Policy Rules > Edit Service Policy Rule), select the Rule Actions tab and then select the Protocol Inspection tab as seen in the figure below.  Uncheck ESMTP, save and you’re good to.  Mail flows and all is well.

The DNS Library WINS TTL Monitor, despite getting some updated verbiage in the MP Guide, still appears to be broken.  The guidance now specifically mentions that you need to create an A record in DNS, and provides some override information.  No matter though, even with creating the A record “placeholder” in the forward lookup zone that corresponds to the domain name of the Ops Mgr management server (i.e. placeholder.mydomain.local), the alert still comes in.  Refer back to my previous post about that item.  So…this monitor gets overridden again.

DPM 2007 SP1 setup leaves Microsoft Visual C++ Redistributable Package installation files in the root directory. You can manually delete the installation files.

Anyhow, here’s a quick and dirty batch (.bat) file that you can run on the local machine to delete the files.

Get it here:  Note: There is a file embedded within this post, please visit this post to download the file.

Now it appears that perhaps error 3013 is making a comeback with the installation of DPM 2007 SP1.  On a fresh install of Windows Server 2008 x64, DPM 2007 x64 was installed and then SP1 for DPM 2007 x64 was applied.  The Reporting feature was verified working before SP1 was installed, but stopped working after SP1 was applied.

The error text:

DPM could not connect to SQL Server Reporting Services server because of IIS connectivity issues.

On the computer on which the DPM database was created, restart the World Wide Web Publishing Service. On the Administrative Tools menu, select Services. Right-click World Wide Web Publishing Service, and then click Start.

ID: 3013

Unfortunately, the guidance given in the error dialog as well in Troubleshooting Reporting Issues page in Technet don’t really accomplish anything.  Trust me, I’ve tried.  The solution, as others have verified and reported, is almost provided in MSKB 938245…almost, except for one small typo in the instructions and the fact that you really wouldn’t know to get from point A (error 3013 as shown previously) to point B (following the steps in the KB article).  Perhaps the DPM team will see to it to have the documentation updated again for Windows Server 2008.

Anyhow, you should be able to get your Reporting functionality working again by completing these steps.

1. Close the DPM 2007 Administrator Console.
2. Open the Internet Information Services (IIS) Manager, be sure you didn’t accidentally open the Internet Information Services (IIS) 6.0 Manager.
3. Expand Web Sites, expand the Default Web Site, and then click the virtual directory for the report server.  By default, this would be ReportServer$MS$DPM2007$.
4. In the middle pane, while in Features View, double-click Handler Mappings in the IIS section.
5. In the right pane, under the Actions section, click Edit Feature Permissions.
6. Click to select the Scripts check box, and then click OK.
7. Open the DPM 2007 Administrator Console and get some reporting done!

Setting the WINS TTL Monitor

The Windows Internet Name Service time to live (WINS TTL) monitor performs an NSLOOKUP query for a test (A) record named “placeholder” to verify that WINS resolution is working properly.  You will need to create a test record called “placeholder” or create an override to change the target name.

Setting the Global Zone Resolution Monitor Target

The global zone resolution monitor performs an NSLOOKUP query for a test (A) record named “placeholder” to verify that global zone resolution is working properly.  You will need to create a test record called “placeholder” or create an override to change the target name.

However, what really seems to happen is no matter what you do (or at least no matter what I did), you’ll still get the “The WINS Connector has stopped working” alerts.  I tried individual overrrides, I tried a type override, I used upper case hostnames, lowercase  hostnames, IP addresses, even tried creating a WINS record named PLACEHOLDER.  No joy.

My solution:  disable the monitor (DNS Library WINS TTL Monitor) until Microsoft updates the management pack.  Have you been able to get it working?

Failed Accessing Windows Event Log

The Windows Event Log Provider was unable to open the System event log on computer ‘{69E3F0CF-36C3-9FDC-1892-42FB003E34DB}’ for reading. The provider will retry opening the log every 30 seconds. Most recent error details: The RPC server is unavailable. One or more workflows were affected by this. Workflow name: Microsoft.Windows.DHCPServer.Library.Server.UnitMonitor.DependentServiceHealth Instance name: myserver.mycompany.local Instance ID: {69E3F0CF-36C3-9FDC-1892-42FB003E34DB} Management group: MyCompany-SysCtrOpsMgr

It seems that the DHCP MP v6.0.6383.0 introduced this annoying bug that seemingly had no solution.  Well, I guess it really didn’t have a solution…until the next version was released.  That version, v6.0.6452.0, was released in November and seems to fix the problem.  Before you import this updated version though, be sure to remove any exisitng DHCP management packs.  Per the included documentation:

Before you import the Windows Server DHCP Management Pack, take the following actions:

• Perform a full backup of the Operations Manager 2007 database.
• Uninstall any existing DHCP management packs. You may wish to record custom overrides and rules for possible inclusion in the new DHCP management pack.

Of course, the fix for this bug isn’t documented in the release notes, but none the less it does appear to be fixed.

The following list contains the issues that are fixed in version 6.0.6461.0 of the Exchange Server 2007 Management Pack for System Center Operations Manager 2007:

• Updated the display name of the top level folder in the Operations console to “Exchange Server 2007 (Converted)”.
• Changed how the management pack monitors disks. Previously, disk monitoring rules lacked alert suppression.  The following rules and monitors were disabled:
  • Disk % Free Space low - Red(<10%)
  • Disk % Free Space low - Yellow(<15%)
  • Disk Free Megabytes low - Red(<20MB)
  • Disk Free Megabytes low - Yellow(<40MB)

The following rules were added:

• Disk Free Space Low Red Rule (by default alerts if any disk has less than 20MB free space)
• Disk Free Space Low Yellow Rule (by default alerts if any disk has less than 40MB free space)
• Disk Percentage Free Space Low Red Rule (by default alerts if any disk has less than 10% free space)
• Disk Percentage Free Space Low Yellow Rule (by default alerts if any disk has less than 15% free disk space)

The new disk monitoring rules support alert suppression. It is also possible to use the Server Operating System Management Pack to monitor Exchange disk space, if desired. In that case, the above rules can be disabled.

SQL Server Management Pack version 6.0.6460.0 includes the following changes:

• The DB discovery script no longer casts the values that correspond to “Database Size (MB) (Numeric)” and “Log Size (MB) (Numeric)” as INT, to avoid overflows exceptions within the script itself.
• The DB discovery script now checks for possible overflow on the “Database Size (MB) (Numeric)” and “Log Size (MB) (Numeric)” values and prevents those overflows from occurring.
• For the numeric properties on the database class we are limited to 2147483647 MB (~2047 TB).  In the event that a DB or log file exceeds that size then the value will be set to the maximum possible value of 2147483647 to prevent overflows.  In these instances the ”Database Size (MB) (String)” and “Log Size (MB) (String)” will support larger values.