Windows Update error 80072F78 in Windows Server 2008
Although I haven’t actually found the exact cause (and thus the solution), I’ve run across problems using Symantec Endpoint Protection (i.e. Symantec Corporate 11.0) on Windows Server 2008. It seems that something in the protection configuration in the Symantec product is blocking Windows Updates. You’d get the error code 80072F78 and no updates.
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.
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”
Exchange Server 2007 SP1 Update Rollup 5 SCR bug
I ran across this the other day while trying to get SCR setup on the Exchange servers in our warm DR site…when trying to run the Enable-StorageGroupCopy cmdlet to configure the SCR instance you get the following error:
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!
Exchange 2007 problem over site-to-site VPN with Cisco ASA
I’m currently working to get a new warm DR site up and running with Active Directory, Exchange Server 2007 SCR and Data Protection Manager 2007. After installing and configuring the Hub Transport server in the DR site, I sent a test message using bmail to my mailbox to test SMTP connectivity and routing between sites. I certainly didn’t expect to find what I did.
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.
Ops Mgr DNS Management Pack updated
The DNS Management Pack for Operations Manager 2007 has been updated again to version 6.0.6480.0, but it still doesn’t seem to fix the the major complaint with the previous version (6.0.6278.27).
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.
Cleanup after DPM 2007 SP1 installation
You might have noticed, if you’ve installed SP1 for Data Protection Manager 2007, that it leaves behind the Visual C++ 2008 Redistributable package contents in your root directory. Tsk, tsk. How did that slip through beta, but yet be specifically called out in the Release Notes?
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:
Visual_C_2008_Redist_cleanup.zip (325 bytes, 928 hits)
Data Protection Manager 2007 SP1 turns off Reporting?
Although it’s been reported in the past that you might sometimes see Data Protection Manager 2007’s error 3013 on a Windows Server 2008 system, whereby SQL Reporting Services is not available, it seemed to be rare.
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.
- Close the DPM 2007 Administrator Console.
- Open the Internet Information Services (IIS) Manager, be sure you didn’t accidentally open the Internet Information Services (IIS) 6.0 Manager.
- 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$.
- In the middle pane, while in Features View, double-click Handler Mappings in the IIS section.
- In the right pane, under the Actions section, click Edit Feature Permissions.
- Click to select the Scripts check box, and then click OK.
- Open the DPM 2007 Administrator Console and get some reporting done!
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.
Ops Mgr “The WINS Connector has stopped working”
Seems that the v6.0.6278.27 DNS management pack for Operations Manager 2007 has its own bug of fame. The “The WINS Connector has stopped working” alert will likely become familiar to you courtesy of the DNS Library WINS TTL Monitor. It seems that the MP ships with the “hostname” field filled in with “Placeholder”…but if you read the relase notes you’ll know this and know to fill it in with the NETBIOS name of something on your network or to create a WINS record for the host named PLACEHOLDER.
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?
Ops Mgr 2007 “Failed Accessing Windows Event Log”
If you’ve been getting these errors from your Operations Manager 2007 DHCP Management Pack, the solution is at hand! Here’s the typical error you’d get:
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.
-
Translator
