DPM across Domains

I've been using the Microsoft System Center Data Protection Manager product for just under 4 years; and I really like the product. As far as I am concerned, it ticks a load of the relevant boxes; easy to install, easy to use and manage, and most importantly, it works really well. It backs up to disk, then from disk to tape. It uses a relatively small amount of bandwidth and data recovery is quick and easy. It is simply one of the best backup products that I have come across, far easier to use than many of the more well known software packages.

A while ago, the company bought out a partner organisation. This left us a sales office based in Paris; they are a separate entity, but as they are quite small, they don't have their own IT staff. They have been using the services of another business, but it was decided a while ago that we would take on that responsibility. We needed to provide a backup function to preserve their data, and set about putting this into place.

One of the key issues was that they did not have an Active Directory domain on site. Everything was set-up as a workgroup only, and this causes a lot of issues. So one of the first things to do was set-up a suitable domain structure. Hopefully, this will reduce the amount of admin work that is required; previously, it was necessary to create a local user account on every single piece of kit, which required a lot of work. The new domain was created a couple of weeks ago, and we've now also created a two trust between the two AD domains.

The next step was to set-up the remote site to be backed up by our DPM server, but this was where we hit a snag. Each time we tried to install the agent, it responded with messages that the remote site was not available. I could prove that this was false; I could ping the remote server and even RDP to it from the DPM server. I checked all sorts of things, and each showed that the remote site was fully operational and accesible.

So I decided to do a manual install of the agent on the remote site. The first step was to RDP to the remote server, then create a mapped drive back to the DPM server. Having done that, I then opened the folder where the DPMAgentInstaller.exe file was found - that's at \Program Files\Microsoft DPM\DPM\Agents\RA\\i386 and there are also options for AMD & 64 bit installs.

This actually went through OK, and having installed the agent, it's necessary to define which is the correct DPM server. This is done using \Program Files\Microsoft Data Protection Manager\DPM\bin\SetDpmServer.exe – dpmServerName . Again this went through OK, but it still produced an error message that there were insufficient permissions to complete the process.

After having checked the event log, I was able to see a number of LsaSrv Event ID: 6033 errors. This showed that I should modify the registry key \Program Files\Microsoft Data Protection Manager\DPM\bin\SetDpmServer.exe – dpmServerName to disable the anonymous logon block. Having done this, it then showed another set of errors taht indicated that there was still a problem with permissions.

Having checked these yet again, I could see that the DPM server was in the correct groups etc. but I also thought to put the DPM administrator account into the administrators group account. Having done this, the error went away, but the agent still wouldn't connect to the DPM server. However, I ran the SetDPMServer.exe utiltiy again, and this time, it completed correctly. When I went back to the DPM console, it showed the agent as installed and connecting to the remote server.

So now we are in the position where we can actually backup that remote site. It will be a bit of an issue to begin with as there is a lot of data on site. I'll probably go over again, to do a manual copy of the data to a portable hard drive. This can then be manually copied to the DPM server to get the initial data load, and then the synchronisation process will only work on the data that has changed from that copy; a great deal less than the full synch process.

This is going to make a huge difference to the people on the remote site; they won't have to worry about tapes etc. or what to do if someone goes on holiday. The data is being backed up off site, so is more secure. The recovery process is really simple and we can give them the confidence that we can deal with it really quickly if needed.