SRKegger

Microsoft Visual C++ 2005 Redistributable Package (x64) was already installed. Microsoft Visual C++ 2008 Redistributable Package (x64) was already installed. The MSXML 6.0 Parser was already installed. Any other ideas?

The version of DPM is 2012 SP1 (4.1.3465.0). The target server is on Server 2008 Enterprise R2 SP1. I'll take a look at the article now. Thanks!

Hello Everyone, I've been stuck on an issue for some time now in trying to get a DPM agent install accomplished on a certain server. The DPM server resides on a parent domain and the server that I am having an issue with is on a child domain. Other servers on the child domain have installed the agent without issue when doing it manually. Here is the command I use (as an administrator): net use X: \\DPMSERVERNAME.parentdomain.com\c$ cd /d X:\Program Files\Microsoft System Center 2012\DPM\DPM\agents\RA\4.1.3465.0\amd64\1033 DPMAgentInstaller_KB2991995_AMD64.exe dpmservername.parentdomain.com The installation proceeds through the Microsoft License Terms, begins to install and then backs out. The error message that is generated states: "DPMAgentinstaller failed with error code = 0X80070643 error says: fatal error during installation" Thinking that there was a firewall issue I ran the suggested fix found here: http://serverfault.com/questions/502476/system-center-2012-protection-agent-remote-install-failed/502803#502803 The issue persists. The MSDPMAgentinstall log file says the following at the end: Property©: Date = 1/7/2015 Property©: MsiNetAssemblySupport = 4.0.30319.18408 Property©: MsiWin32AssemblySupport = 6.1.7601.17514 Property©: MsiRunningElevated = 1 Property©: Privileged = 1 Property©: USERNAME = Windows User Property©: DATABASE = c:\b1e38ee30069ed00e510\DPMRA.msi Property©: OriginalDatabase = c:\b1e38ee30069ed00e510\DPMRA.msi Property©: SOURCEDIR = c:\b1e38ee30069ed00e510\ Property©: VersionHandler = 5.00 Property©: ROOTDRIVE = c:\ Property©: EXECUTEACTION = INSTALL Property©: ACTION = INSTALL Property©: UILevel = 5 Property©: CostingComplete = 0 Property©: OutOfDiskSpace = 0 Property©: OutOfNoRbDiskSpace = 0 Property©: PrimaryVolumeSpaceAvailable = 0 Property©: PrimaryVolumeSpaceRequired = 0 Property©: PrimaryVolumeSpaceRemaining = 0 MSI © (68:E8) [09:38:14:119]: Note: 1: 1708 MSI © (68:E8) [09:38:14:119]: Note: 1: 2205 2: 3: Error MSI © (68:E8) [09:38:14:119]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1708 MSI © (68:E8) [09:38:14:119]: Note: 1: 2205 2: 3: Error MSI © (68:E8) [09:38:14:119]: Note: 1: 2228 2: 3: Error 4: SELECT `Message` FROM `Error` WHERE `Error` = 1709 MSI © (68:E8) [09:38:14:119]: 吰瞒 MSI © (68:E8) [09:38:14:119]: 吰瞒 MSI © (68:E8) [09:38:14:119]: Grabbed execution mutex. MSI © (68:E8) [09:38:14:119]: Cleaning up uninstalled install packages, if any exist MSI © (68:E8) [09:38:14:119]: MainEngineThread is returning 1603 === Verbose logging stopped: 1/7/2015 9:38:14 === The 1708 error lead me to the fact that maybe the firewall on the target server was the issue, but I followed the suggested changes to the firewall on the target server and the installation still fails. Any ideas on where to turn next?

This was an easy one it turns out. Layer 2 needed to be extended across the WAN for these networks that were failing. Basically the Microsoft guy needed to explain to the Cisco guy how the traffic flows. Specifically how the Microsoft Failover Virtual Adapter works using UDP traffic got a, "Oh yeah. We still need to open up layer 2 traffic for those networks. I'll get on that." All is now right in the world.

Thank you for the suggestion. Indeed Wireshark shows port 3343 is open between the two nodes. A new twist on this is that the above mentioned netadmin got on the server over the weekend and reset the TCP/IP stack. The interesting thing is now the heartbeat network pings, but other networks that I set up for iSCSI fail, and only from one node and not the other. Here is a sample from the validate network report: Network interfaces node01 - ISCSI 1 and node02 - iSCSI 1 are on the same cluster network, yet address 10.0.32.20 is not reachable from 10.0.32.15 using UDP on port 3343. Network interfaces node02 - iSCSI 1 and node01 - ISCSI 1 are on the same cluster network, yet address 10.0.32.15 is not reachable from 10.0.32.20 using UDP on port 3343. For example, from node02 I can ping 10.0.32.15 which is the interface for iSCSI on node01 fine. From node01 when I ping 10.0.32.20 which is the iSCSI interface for node02 it fails. In Failover Cluster Manager the status for this network is "Up", but within that under the Network Connections tab the staus for this interface is "Unreachable". I have the adapters set up using the suggestions for iSCSI found here: http://www.server-log.com/blog/2011/8/4/hyper-v-cluster-cluster-network-settings-overview.html So now, each node has an interface for heartbeat which pings fine each way, and an interface for live migration which pings fine each way. 3 interfaces are set upfor iSCSI which ping fine from node02, but fail from node01. Why would some interfaces fail while others succeed? (Note: The only commonality is that each adapter that fails is a HP nc382i dp multifunction gigabit server adapter and the other adapters are HP NC375 PCI Express. I have updated all firmware and driver updates from Broadcom and HP)

I have a question regarding setting up a heartbeat between two nodes on a cluster (In this case Windows Server 2012) when the nodes are on separate physical sites connected over a WAN. When the public NIC's can ping each other and theheartbeat cannot, what usually is the issue? When I run the cluster validation test I get the following result: Network interfaces SERVER01 - Heartbeat and SERVER02 - Heartbeat are on the same cluster network, yet address 10.0.36.20 is not reachable from 10.0.36.15 using UDP on port 3343. I've checked the firewall on each server and port 3343 is open. I've asked the netadmin who oversees the Cisco router configurations whether port 3343 is blocked or not and he assures me it is not. Any ideas and suggestions will be appreciated.

DPM 2012 and deduplication question here. It's my understanding that the volume DPM uses for storage should not be deduplicated. I have a client who is very concerned about storage space, or lack thereof. Because of that they have latched onto the buzzword of "deduplication" as a solution. What solutions are out there that would reduce storage space on the volume DPM uses (which is an iSCSI array in this case) especially in comparison to solutions Backup Exec has to offer?

After upgrading to SP1 I can no longer schedule Windows updates on an operating system image. The Scheduled Updates Status goes from "Processing", to "Failed to mount the image on the system". This feature did work prior to upgrading to SP1. I have made sure that Endpoint Protection has C:\ConfigMgr_OfflineImageServicing as an exception. I've also tried uninstalling WSUS 3.0 SP2 and installing it. I've included the OfflineServicingMgr.log file. Any suggestions on how to proceed will be appreciated. OfflineServicingMgr.log

Fixed. I was using the x86 boot image for a Windows 7 64 bit OS due to issues with NIC drivers for the x64 boot image. Once I cleaned up the driver issues for the x64 and implemented that into my task sequence it ran fine.

Hello. I'm having a similar issue as others in this forum when running a Build and Capture task sequence. I'm using the Boot image (x86), CM Client Upgarde version 5.0, and a Windows 7 OS installer. The sequence runs fine all the way to completing the download the content to the target system and then fails with the 0x80004005 error. I've looked over the smsts log file and I cannot see any issues with my untrained eye. I'm hoping someone can point me in the right direction. I've attached the smsts.log file. Thanks! Edit: I submitted the wrong smsts.log file. This one is now from x:\windows\temp\smstslog smsts.log