DPM Support - From the Frontlines Straight to You

Connect-DPMServer.ps1 will not connect

blogdpm — Mon, 08 Jun 2009 04:40:23 GMT

Interesting case that I just resolved.

Customer is using a third party software to perform SharePoint restores. While trying to connect back to the DPM server from the other SharePoint application restoration server he was getting the following error:

After taking network traces and DPM MPS Reports, we started doing code reviews of how the connect-dpmserver.ps1 script works.

When you perform a connect-dpmserver.ps1, we initiate communication to the DPM server via RPC. Once the RPC connection is made, we then talk to the SQL server via TCP/IP.

We use a setting from the registry to let the connecting server know what the name of the server is and the instance of SQL that we try and connect too. In a default installation the database name is MS$DPM2007$. The connection string should reference <servername>\\\MS$DPM2007$. In our customers situation the connection string was localhost\\\MS$DPM2007$.

This caused the connecting server to initiate communication to the DPM server and then the DPM server told it to connect to the local host; there was no DPM database on this server because only the DPM Management Shell was installed.

After changing the connection string we saw the following:

Why was it still failing? DPM caches the information it collects from the registry to hand back to the servers that are trying to connect to it via the connect-dpmserver.ps1 script. Not until we either restart the DPM service or reboot the server will DPM be re-populated with the correct information.

After restarting the DPM service we now see the following:

Walt Whitman

Support Escalation Engineer

Microsoft Platforms Core Team: DPM

Recovery of a Mirrored SQL Database

blogdpm — Fri, 29 May 2009 17:51:02 GMT

Recovering a mirrored database, whether it is to a SQL Server 2005 or SQL Server 2008 installation, requires that the existing mirror be broken. For simplicity, you may want to consider deleting both the Principal and Mirror databases and using the latest recovery point that DPM has in order to restore the data.

This blog post is geared towards a simple database mirroring recovery scenario and doesn’t discuss the replaying of transaction logs as part of the recovery process. As with any blog post, if there is additional information you would like to see provided or questions you would like to see answered, please pass those comments and questions along so that we can consider those for future posts.

This blog also includes a video demonstration of the recovery process involved in recovering a mirrored SQL database.

In our scenario, we will work under the premise that a bad transaction has been posted to the database and replicated without any means of backing it out cleanly. Now we have to restore the database to the servers and establish mirroring again. We will not consider the restoration complete until DPM is able to create a new recovery point after the restoration. This is a standard measure used to define when a recovery has been completed successfully.

Considering the scenario we have described, let’s begin.

In the screenshot below, we see that we have database corruption which needs to be recovered.

We begin by opening the properties of the Principal database and going to the Mirroring page. On the right side of the page is a button titled “Remove Mirroring”. Click on this button and confirm the selection by clicking on the “Yes” button in the following dialog to remove mirroring. After mirroring has been removed, you will be able to begin the restoration process.

If mirroring is left enabled, then DPM will fail on the restore with a detailed error message indicating that mirroring is still enabled and must be removed before the restore can be completed successfully.

With mirroring broken, delete both copies of the database on the Principal and Mirror servers. During the restore, you will decide which will be the Principal and which will be the Mirror based on how the restore to each server is performed.

With each database deleted, begin the recovery process by navigating to the Recovery tab in the DPM Admin console and selecting the recovery point you wish to restore. When the “Specify Database State” page of the Recovery Wizard appears, you will have the option here to choose whether this server will be the Principal or the Mirror.

In the screen shot below, you will note that the “Leave database operational” radio button has been selected which indicates that the server selected will become the Principal server.

Before you start the recovery to the Mirror server, you must make sure that you are recovering using the same recovery point that was used for the Principal server’s recovery. If not, you will receive errors when attempting to establish mirroring between the two copies of the database.

When the recovery has progressed far enough along that you can begin another recovery, you can start the Mirror database recovery. In the “Specify Database State” page of the Recovery Wizard, make sure that you choose the radio button for “Leave database non-operational but able to restore additional transaction logs”. This will restore the database with the “Restore with NoRecovery” option enabled. As you recall from the blog on establishing a database mirror, this is a requirement when seeding the Mirror server.

This radio button helps to minimize the number of steps involved in the recovery process.

Once both of the restores have been completed and the Principal and Mirror database servers have the same copy of the database restored, you should verify that the necessary data has been restored to the server. If the expected data is still missing, you may need to consider restoring from a different recovery point.

If there are additional transactions that need to be replayed, consider creating the mirror and then replaying the transactions so that SQL will replicate them on the fly to the mirror.

With the data having been restored to both servers, now it is time to run the “Database Mirroring Wizard” from within SQL Server on the Principal server and setup mirroring on the database. Once mirroring has been established, you have completed the portion of the data restore that your users are concerned about.

You have not completed the restore from a DPM perspective, however. There is still an additional step to consider.

Since the database was recovered to its original location, DPM will not be able to create any additional Recovery Points until a consistency check has been run on the database. Once this consistency check has completed successfully, a new recovery point will be created.

From the DPM perspective, this newly created recovery point confirms the successful completion of the mirrored database recovery.

Summary

In recovering a mirrored database, the mirror must be broken first. After the mirror has been broken, the same recovery point must be used when populating the Principal and Mirror servers.

After the restore has been completed and the data verified, the mirror can then be recreated. Before DPM can continue to protect the mirrored database, a consistency check will need to be run. Once complete, a new recovery point will have been created and DPM will be able to continue protecting the mirrored database moving forward.

Video

Vic Reavis
Support Escalation Engineer
Microsoft Enterprise Platforms Support

Protecting Mirrored Databases with DPM 2007 SP1

blogdpm — Fri, 29 May 2009 17:50:15 GMT

Considering the vast amount of mission critical data stored on SQL servers globally, the high availability of database mirroring with the frequent snapshots of DPM make protection and recovery scenarios much less fearful for administrators entrusted with protected SQL data.

Database mirroring protection can be thought of as a blend between SQL Failover Clusters and stand-alone SQL Servers. As with SQL Clusters, DPM is able to follow the database as it is failed over from one node to another. At the same time, DPM still provides the same level of protection scheduling options and recoverability as it does with stand-alone SQL databases. DPM is also capable of protecting a mirrored database when it is encrypted, via the use of certificates, or if the mirroring configuration spans domains or even forests.

Since we have a fundamental understanding of database mirroring based on the blog “SQL Database Mirroring for DPM Administrators”, let’s dive in and discuss what is needed to protect a mirrored database.

There are videos available for viewing as supplements to this blog which demonstrate the protection of a mirrored database which spans a Windows Failover Cluster on the Principal side and the Mirror server as a stand-alone SQL server. Another video covers a basic database mirror across a pair of stand-alone SQL Servers, while the third demonstrates what happens when a protected database is mirrored after protection has been running for some time.

Establishing Protection

When establishing protection of a SQL Server 2005 or SQL Server 2008 mirrored database, you will need to confirm that the DPM Agent has been installed on both the Principal and Mirrored servers. This is a requirement in order to implement protection. If one side of the mirror is a Windows Failover Cluster, then both nodes of the cluster and the SQL Mirror server must all have the DPM agent installed.

In the following example, we will protect the AdventureWorks database which has been mirrored across a stand-alone server and a 2-node failover cluster. All 3 servers involved have the DPM agent installed already.

As we see in the Create Protection Group wizard, the datasources for the cluster as well as the stand-alone server have been displayed. Notice that text has been appended to the name of the AdventureWorks database which tells which physical or virtual server the database mirror extends to.

Continue through the wizard setting up the disk and tape protection, the retention range, synchronization frequency, etc., until the wizard completes. At that point, the initial replica of the protected data will be taken if you have chosen the appropriate option in the Choose Replica Creation Method page of the wizard.

After a period of time, the Protection Status in the Protection tab will show OK for the newly created protection group. DPM is now able to protect the mirrored database you have selected. As with all things however, the database will not remain on the current Principal server for the remainder of eternity. So what happens when there is a failover of the mirror and the mirroring roles are switched?

Immediately, there will be no indication that DPM has a problem protecting the database. If the mirrored database fails back to the original node before the next recovery point or sync is run, then DPM will continue protecting the data source as if nothing happened. If the database is on a different server than expected by DPM, then DPM will fail to successfully create a recovery point.

The error will be specific in its detail and will read like the following.

Error 32015: DPM is unable to continue protecting the selected database because DPM detected a mirroring session failover for this database.

Recommended action: Run a synchronization job with consistency check.

Simply running a consistency check will take care of the problem and future recovery points should complete successfully. If the failover occurs and there is no one able to get to the server to force a consistency check within 30 minutes after the failure, DPM will automatically run one. This can be seen in the Monitoring tab of the DPM Admin Console under the Jobs tab. Look for the failed Recovery Point job that was run after a mirrored database failover. Look for a Consistency Check (CC) job to run 30 minutes later on the same data source. When that CC runs to completion, a Recovery Point will be created as well. This can be verified by reviewing the available Recovery Point in the Recovery tab for that data source.

Changes in State

In situations where a protected database’s mirrored status changes, DPM will not be able to create a Recovery Point until you stabilize the data source because DPM will detect the change in state. Anytime a database goes from non-mirrored to mirrored or vice versa, the data source will need to be removed and added to the protection group again.

The reason is that during the creation of the protection group, DPM scans the server on which the database resides to see if it is mirrored or clustered with other servers. Because of the enabling or disabling of mirroring on the database, DPM will need to either add or remove dependent servers from the database in question.

Once the SQL datasource has been updated and added to the protection group, the Initial Replication will run and a new recovery point will be created. A word of caution: when reviewing the recovery points for the database after a change in mirroring state has been made, you will see two entries for the same database and each will have recovery points available for restore.

DPM does not distinguish in the Recovery tab between the recovery point copies that were and were not mirrored.

Videos

Summary

In this blog, we discussed how to protect a mirrored database and how to stabilize DPM’s protection of the mirrored data source when failover occurs and we discussed what happens when mirroring is enabled or disabled on an already protected database. Take a look at the included video content for a demonstration of the actions covered here.

Vic Reavis
Support Escalation Engineer
Microsoft Enterprise Platforms Support

SQL Database Mirroring for DPM Administrators

blogdpm — Fri, 29 May 2009 17:48:19 GMT

This blog focuses on providing a very light-weight overview of how to implement SQL database mirroring and it is not intended to be a complete how-to reference. DPM administrators benefit by understanding, even at a basic level, how to install and configure the applications DPM will be protecting. This blog is intended to provide some of that knowledge as a starting point.

A video demonstration is provided to help guide you through the database mirroring scenario.

Need to Know

Support for SQL Database mirroring was introduced with SQL 2005 SP1. Before that, it was not a supported feature in SQL Server 2005.

Before implementing database mirroring, you must confirm that the Recover Model of the database is set to FULL. Full is the only recovery model that mirroring supports. The Full recovery model provides the normal database maintenance model for databases where durability of transactions is necessary.
Log backups are also required. This model fully logs all transactions and retains the transaction log records until after they are backed up. The full recovery model allows a database to be recovered to the point of failure, assuming that the tail of the log can be backed up after the failure. The full recovery model also supports restoring individual data pages.
For more information, see Backup Under the Full Recovery Model.

SQL Server credentials must match across the servers involved in the mirror or credentials must be provided during the configuration of the mirrored database. In the example which follows, we will work under the premise that the SQL Server service accounts on all servers involved are using the same credentials.

If the mirror will span multiple domains, then Certificates will need to be implemented. Since the purpose of this blog is to provide DPM administrators with a cursory understanding of how to implement mirroring, the use of certificates will not be covered here.

When seeding the mirrored database, the recovery of the database must be done using the (RESTORE WITH NORECOVERY) option. This option leaves the database in a read-only mode to users but allows the Principal SQL Server to still restore transactions to the mirrored copy. SQL Administrators will not be able to pull up the properties of the mirrored database while in this configuration.

Witness servers are a feature that allows SQL to detect failures and automatically failover a database. Without a witness server (which is a 3^rd SQL server distinct from the Principal and Mirror servers) manual failover is the only way to switch the mirror roles.

With the release of SQL Server 2008, a new feature is supported in SQL Server called ‘FileStream’. SQL Database Mirroring does not support this feature and if configured, a detailed error will appear during the creation of the mirror.

Mirroring a Database

The mirroring process between SQL 2005 and 2008 has enough over-lap that we can cover one, in this case mirroring of a SQL 2005 database, and still have a sound enough understanding of how a SQL Server 2008 database can be mirrored using the same steps. For this reason, we will cover the SQL 2005 database mirroring process. Further details can be found in the SQL Server section of the TechNet web site at http://technet.microsoft.com/en-us/library/bb545450.aspx.

Mirroring AdventureWorks

As with any database that will be mirrored, start by opening the properties and setting the Recovery Mode to “Full”, if it is not already.

Once this has been set, you will now need to make a backup of the database. Make sure it is a Full backup and for convenience, make sure that you are not using the Append option so that the BAK file size is minimized and the restore is less confusing.

On the mirror server, you will need to restore the backup of the database that you just made as part of the seeding process.

Make sure that when you perform the restore that you choose the middle radio button as shown below. If the restore is performed without the “RESTORE WITH NORECOVERY” option, SQL will not be able to setup mirroring between the two servers.

Now that the mirror server has a copy of the database restored to it, go to the Principal server and begin the mirror setup. When the Mirroring page of the database properties appears, click on the Configure Security button in the upper right corner of the window as shown below.

Decide whether you will be using a 3^rd SQL Server as a Witness server and then click on Next.

If you have not setup mirroring previously, you will need to specify the port for mirroring to use and give the endpoint a name. This endpoint will be created on each server and can be viewed from SQL Management Studio.

Configure each server and confirm connectivity as well as the security credentials. Once connectivity has been confirmed and the SQL Service account credential information has been specified, click on Finish to allow the mirroring to be established between the two servers.

Once mirroring is configured, it is not started so you will have to click on the Start Mirroring button as shown below to begin the transaction replication from the Principal to the Mirror server. If all goes well, you will see the databases appear like the following.

If you want to try to failover the database so that Principal and Mirror roles are switched, click on the Failover button. This will cause a warning dialog to appear confirming your decision. Choose Yes to allow the failover to occur.

Basic Troubleshooting

As a DPM administrator, there is often not a lot of time allocated to troubleshoot setup and installation issues and these types of issues are common when working with unfamiliar technologies. Here are a few of the most common database mirroring configuration issues that arise. Take a look at http://TechNet.Microsoft.com for more detailed information about other failures that you encounter.

If the database is not in Full Recovery mode, the following is displayed. If the restored copy of the database did not have Full Recovery mode setup when it was backed up, then you will need to delete it and create a new backup after making this setting change.

If the mirror copy was not restored using the “RESTORE WITH NORECOVERY”, the following error will be displayed. Simply remove the restored copy of the database and restore it using this option to work around this issue.

In a busy environment, there may be transactions that are not captured. If this is the case, the following error may be displayed. You may need to place the Principal database in single-user mode and backup the transactions. Once these are restored to the mirror server, then try to configure mirroring.

Summary

Database mirroring can be established where one side of the mirror is on a Failover Cluster. You can even have the same SQL server acting in a mirroring partnership with 3 or 4 or more other SQL Servers. This is not a recommended practice however as this configuration can create confusion and, when it comes to DPM protection, all servers participating in a mirroring partnership must have the DPM agent installed. If the agent is not installed on all servers, DPM will not be able to protect the mirrored database.

In an upcoming blog, we will cover the protection of a mirrored database using DPM 2007 SP1. Subsequent blogs will also discuss the recovery of a mirrored database to its original location. When reading the blog on recovering mirrored databases, you may need to refer back to this blog as the recovery process requires the database mirror to be broken and re-established in order to complete the restore.

Vic Reavis
Support Escalation Engineer
Microsoft Enterprise Platforms Support

Intro to DPM 2007-SP1

blogdpm — Fri, 29 May 2009 17:44:12 GMT

In the coming weeks, we will be discussing the new features of DPM 2007 SP1 to enough depth that you can implement them into a new or existing environment. We will also be covering some of the basics on how to install and configure, at a very basic level, the applications that DPM will be protecting.

This information is targeted towards DPM administrators who have little-to-no experience with the technologies that DPM SP1 provides support for such as SQL Database Mirroring, Exchange SCR, Hyper-V, and SharePoint Search index servers.

Here is a summary list of those new features:

Mirrored Database protection for SQL 2005 and SQL 2008 databases
Mirrored Content and Search Index Database protection for SharePoint WSS and MOSS farms
Search Index database protection and recovery for SharePoint farms
Distinct Content Database checking
Exchange 2007 SCR protection
Hyper-V guest OS protection
Cross-Forest Protection
Additional support provided for Local Data Sources which include locally installed Hyper-V guests

Let’s take a look at these features at an introductory level; future blogs will go in depth on how to configure, protect, and recover these new data sources.

Mirrored SQL Database Protection

Database mirroring is a feature introduced with SQL Server 2005 SP1 which allows transactions to be passed to a secondary server (mirror) shortening the failover time needed to bring the alternate database online for user access.

DPM provides support based on the configurations that the SQL Server support teams support. As an example, DPM can protect a mirrored database after failover and without manual intervention. DPM can also protect a mirrored database that spans multiple domains or where one of the partners in the mirror is on a Windows Failover cluster.

The blog on SQL Database mirroring will go into the details of setting up and mirroring a given database and what steps are needed to protect and recover the data. We will also discuss the mechanisms in DPM 2007 SP1 that allow for continued protection after a failover of a mirrored database, whether the failover is manually or automatically instigated.

DPM does not extend limitations of a protected product but is designed to fit within that product’s support scenarios. For example: it is a limitation of SQL that mirroring must be removed in order for any data to be restored. DPM does not work around this limitation, but works within it.

For the full set of features DPM offers with regard to SQL Server database mirroring, please refer to the blog on SQL Database mirroring. The examples provided in the blog cover the protection of a mirrored database where one side of the mirror resides on a Windows Failover cluster.

SharePoint Features

Mirrored Content and Search Index Database protection

As with the protection of mirrored SQL databases, as of SP1 for DPM 2007, protection is provided for any SharePoint content databases that have been mirrored in SQL Server 2005 or SQL Server 2008 along with any Search Index databases that have been mirrored in SQL.

Search Index databases protection

Prior to SP1 for DPM 2007, the failure or corruption of a search index database could result in re-crawling of the sites in a farm and this process in large implementations could run for more than 24 hours. With the release of SP1, DPM is able to restore the index database to its original location so that a subsequent crawl of the SharePoint content could be reduced from 24 hours to just 2-3 hours. This saves stress on users who actively search for content and reduces recovery down-time by allowing administrators to effectively seed the search index database and then run a crawl to update the database with any changes.

Distinct Content Database Checking

Invariably, content databases in large farms will become inconsistent from time to time. Prior to SP1 for DPM 2007, if any content database became inconsistent, the entire farm went unprotected until the consistency checks for every database completed. Forcing healthy data sources into an unprotected state due to one or two unhealthy data sources was not ideal for large SharePoint farms.

As we will see when this feature is discussed in greater detail in a later blog, any content database that is showing as “consistent” will see its job moved immediately into the Completed Jobs list. Any remaining databases whose state is “ inconsistent” will remain until the consistency check completes on those respective databases. At that point, the consistency check job for the Farm will run and complete.

This ability becomes of paramount importance considering that the failover of a mirrored content database renders that content database inconsistent until the automated consistency check job runs to correct this issue. The time savings of being able to isolate a content database in order to run a needed consistency check, as compared to the entire list of databases in the farm, will be the greatest for the largest SharePoint farms.

Exchange SCR Protection

Exchange Server 2007 Service Pack 1 introduced a new replication topology called Standby Continuous Replication, or ‘SCR’ for short. In an upcoming blog on SCR protection, we will learn about SCR and what configurations are supported.

We will also discuss how to setup SCR on a mailbox database and how to protect the Source and Target servers. Protecting the Target SCR server is crucial as Exchange does not natively provide backup support for the Target server, only the Source server. To fill this gap, DPM 2007 SP1 introduces this capability.

Because Exchange SCR configuration and management is handled from within the Exchange Management Shell CLI (Command Line Interface) and not from the Exchange Management Console, the blog will cover the switches for the necessary cmdlets in detail. Familiarity with PowerShell is needed for support of this technology and extra detail is provided in the appropriate blog.

We will also cover the recovery capabilities and limitations imposed by Exchange, as there are some limitations we must work within due to the way SCR is implemented within Exchange.

Hyper-V Guest OS Protection

Virtualization technologies like Virtual Machine Manager and Hyper-Visor (Hyper-V) have become widely adopted because of the tremendous cost savings provided by each. With the release of Service Pack 1 for DPM 2007, protection of the Hyper-V guests becomes another key area of protection that must be filled.

DPM’s ability to protect Hyper-V guests covers a rich array of capabilities that include the ability to protect guests in a Hyper-V host installation based on Windows Server 2008 Core as well as the Full versions. With Integration Services, the Hyper-V VSS writer makes it possible for DPM to protect guests that are live without having to pause or save them, which would interrupt user connectivity.

One limitation is that DPM does not protect all other drives connected to the guest OS. In cases where iSCSI connections to other storage exists in the guest, the DPM agent should be installed inside of the guest partition to provide a protection solution of the additional iSCSI volumes.

For guest operating systems that do not support Integration Services like Windows NT 4.0, DPM will pause the system before a backup is taken. This means that DPM is now capable of protecting Windows NT 4.0, Windows 2000, and Linux systems that are guests of a Hyper-V host system. In these situations, DPM will only backup the local storage (VHD) files and not remote disks. Using this method, DPM is also capable of protecting dynamic disks inside of a VM and pass-through disks (physical host-machine disks mapped to a VM for use).

When the offline backup is taken, DPM requests the machine to be paused. The paused system’s VHDs are then snapshot, and the guest OS is brought back online.

DPM is able to restore the base files to any location or the full guest back to its original location. When restored to its original location, the administrator only needs to power the system on and verify the data is there. No other configuration changes are necessary within the Hyper-V Manager.

Clustered guests can also be protected by DPM as long as both host systems have the DPM agent installed so that regardless of which system the guest is online and running on, the DPM Server can contact an agent to initiate protection of the files. DPM also supports Virtual Machine Manager (VMM) Quick Migration.

Cross-Forest Protection

The ability to protect data sources on a server in a different domain within the same forest has been a feature of DPM since its initial release. With the release of SP1 for DPM 2007, protection is now being provided across a 2-way forest-to-forest trust. The only requirement for this feature is that the cross-forest trust must be 2-way.

Cross-forest trust provides a new type of Windows trust for managing the security relationship between two forests—greatly simplifying cross-forest security administration and authentication. Users can securely access resources in other forests without sacrificing the single sign-on and administrative benefits of having only one user ID and password maintained in the user's home forest. This provides the flexibility to account for the need for some divisions or areas to have their own forest, yet maintain the benefits of Active Directory.

Local Data Source Protection

To help Enterprise level customers who have single server installations in remote offices, DPM 2007 SP1 supplements the local data source protection capabilities for files, and folders available prior to SP1 by adding Hyper-V guests as well. With more Enterprise-level customers setting up remote offices with a limited number of multi-use servers, DPM is now capable of protecting data sources locally. Considering also that most remote offices are across low-bandwidth links, there may not be sufficient bandwidth to handle the amount of data DPM must transfer in order to protect it.

Summary

We discussed, at a very high level, several of the new feature offered with the release of DPM 2007 SP1. From this blog, we will move into more in-depth discussions of each feature. We will demonstrate how to implement the basic features of the applications DPM protects for DPM administrators since a cursory knowledge of each protected application is necessary for implementing and managing protection with DPM.

Vic Reavis
Support Escalation Engineer
Microsoft Enterprise Platforms Support

Installation and Rollback of DPM SP1

blogdpm — Fri, 29 May 2009 17:38:43 GMT

Well, the day has come and you are thinking about installing SP1 for DPM 2007 to your DPM environment. There are a few things you that you need to be aware of before you install this Service Pack to any DPM servers. Let’s take a moment to discuss these before unleashing SP1 into your environment haphazardly. In the event you do make the decision to back SP1 out of your DPM environment, we will cover the steps needed to make this happen. Of course, we will first discuss how to best prepare for the installation of the service pack.

To begin with, DPM 2007 SP1 includes a lot of new functionality as well as numerous fixes that will without a doubt stabilize your DPM environment. As with any churn to the binaries on a server, there is always an inherent amount of risk involved. In order to mitigate the risk involved and try to make this as positive an experience as possible, take some precautionary steps.

Do you know what DPM patch level you are running currently without looking at the DPM server?

If you know and are absolutely sure that you know, then kudos to you; since I am a precautionary doubter by nature, let’s confirm. Two ways to confirm this are covered. First, from within the DPM Administrator’s Console, look for the ‘I’ which looks like the informational icon seen in the Event Viewer in the upper right of the console. Double clicking on this will show you a screen that provides the build number of DPM which will appear near the bottom of the screen and may resemble “2.0.8107”. This can be used to determine the patch level of DPM as DPM 2007 without any patches will have a version number of “2.0.5820”.

Alternatively, you can open SQL Query Analyzer and connect to the DPMDB and run the following query “Select name, buildnumber from tbl_AM_AgentPatch”. This query will return the necessary information to determine what the patch level of the DPM Server is.

Now that we have that information, let’s take a look at protecting the data that is currently in production before we introduce SP1.

If you have applied any patches like the Feature Pack from KB949779 which modified the database schema, a backup of the database has already been taken for you. You will find this backup of the DPM database in a file called QFEdpmdb.bak in the C:\Program Files\Microsoft DPM\SQL\MSSQL.1\MSSQL\Backup folder on the DPM server if you have a local installation of SQL on the DPM Server. If your DPM server is utilizing a remote installation of SQL Server, then you will find the backup of the database on the SQL server, under the MSSQL\Backup folder on the server.

Protect this file as this is an older backup that can be used as a last resort before reinstalling from scratch and having to start over with DPM. You may want to consider renaming this file to include the build number of the database that it contains. Next move this file into a safe location.

With that file protected, you will now need to open a command prompt and run the following command to take a backup of the DPM database. Navigate to C:\Program Files\Microsoft DPM\DPM\bin and run the command ‘dpmbackup –db’. Depending on the size of the DPMDB database, it may take some time to complete. Once this backup completes, it will create a file called DPMDB.BAK in the C:\Program Files\Microsoft DPM\DPM\Volumes\ShadowCopy\Database Backups. This backup should be renamed to give you an idea of what the build number is and then the files should be copied into the same folder as the QFEdpmdb.bak file that was moved earlier. Now you have both of your backups labeled clearly so you know what they are and they are safe.

The reason for this is that if SP1 needs to be removed, a full uninstall of DPM will be required and we don’t want these copies put at risk when the server is cleaned up of DPM. Regardless of whether you intend to upgrade DPM to SP1 right away or not, it is strongly recommended that you have a scheduled task run the ‘dpmbackup –db’ command on at least a weekly basis and have that file copied to a location where DPM can back it up. Local Data Source protection was introduced with the Feature Pack from article number KB949779 so this is an option.

With DPM backups taken, and moved to a safe location, you are ready to upgrade your DPM server to SP1.

Returning DPM to a Pre-SP1 version

Invariably, there are some situations that necessitate that DPM 2007 SP1 be removed from the environment while additional testing is done. It will not happen in many cases, but given the odds, it will happen. Let’s now take a look at the steps necessary to return DPM to a working version prior to the SP1 upgrade.

Considering that the SP1 installation routine will take a backup of the DPMDB database during the installation of the service pack, we can utilize that copy of the database for our recovery.

Working under the premise that the QFEDPMDB.BAK file has been moved to a safe location out from under the DPM folder structure as stated above, we will need to uninstall DPM from the server. On a Windows Server 2008 system, this is done by navigating to Control Panel and selecting the Programs and Features option. This will generate a list of installed applications like Add\Remove Programs does for Windows Server 2003.

On both Windows 2008 and Windows 2003 servers, look for the Microsoft System Center Data Protection Manager 2007 entry and remove it. On a Windows Server 2008 system, there is an Uninstall option at the top and in Windows Server 2003, click on the Change/Remove button to the right. This will start the wizard to remove DPM from the server. This is necessary in order to return the server back to a Pre-SP1 build of DPM as the modifications to the database schema cannot be reversed without uninstalling.

Follow the wizard to the Uninstallation Options screen where 2 radio buttons will be presented. The first is the Retain disk-based recovery points button. This is likely the option you will select as these recovery points can be used in recovery scenarios after the DPM server is back up and running with a pre-SP1 build. If you choose the Remove data option, you must understand that any recovery points created previously before and after SP1 was installed will be lost and cannot be recovered.

Click on Next and continue through the wizard until the uninstall of DPM has been completed. There is a notification screen at the end that tells of tasks that were not performed by the uninstall routine. One complete, you will need to reboot the DPM server.

After the server comes back up and you have logged in, you will need to navigate to the SQL Server Management Studio and delete the DPMDB database. This must be done in order for the reinstallation of DPM to be successful. The installation routine will detect if there is already a DPMDB in existence on the SQL server instance selected. Once the DPMDB database has been deleted, you can begin the install of DPM on the server.

Install DPM just as you did originally making the same settings changes during the installation. Once the installation completes and you are presented with the Installation Success screen, unselect the Open DPM 2007 Administrator Console when the wizard closes checkbox. This is not the right time to open the console as this is a plain installation with no data. Choose Close to terminate the wizard. Now the patches that were on the DPM server prior to SP1 will need to be reinstalled. If you have the patch from KB949779 or anything after it, you can start with it and then apply the last patch that was applied to the server. The reasoning here is that from the KB949779 patch forward, all patches were cumulative.

NOTE: If you are unsure what build of DPM you were running, you can restore the DPM database using the following commands and then run the query (“Select name, buildnumber from tbl_AM_AgentPatch”) to see what build number DPM was prior to applying SP1. At that point, you will know which patches to apply.

Once the DPM server has been patched, you will want to rename the new QFEDPMDB.BAK file that was created after applying the KB949779 patch so that you will have a working clean database to revert back to if needed.

Restore the DPM Data

Now that DPM has been reinstalled and patched, you will need to restore the database and get DPM back up and running. In our recovery example, the database (QFEDPMDB.BAK) backup file was moved to C:\DPM_BACKUP folder prior to removing DPM. To restore the data, open a command prompt using Start\Run\’CMD’ and navigate to the C:\Program Files\Microsoft DPM\DPM\bin folder (understanding that this is the folder that DPM was installed to).

Type the following at the command line and press enter.

Dpmsync –restoredb –dbloc c:\DPM_BACKUP\qfedpmdb.bak

This will restore the contents from the backup file into the existing DPM database. Depending on how much data has to be restored, this may take some time.

From the same command prompt, now type and execute the following command.

Dpmsync –sync

This command can take a very long time (hours) for DPM database that are very large and have been protecting large numbers of data sources. As there is no progress bar, do not be alarmed if this process appears to be hung and non-responsive. If the process is still running after 8-12 hours, you may consider opening a support incident with Microsoft.

When it completes, you can then test the DPM installation by opening the DPM Admin Console. If any agents have been upgraded to the SP1 version, you will need to remove the agent and reinstall it which will result in the machine being restarted so this should be taken into account when backing out DPM SP1 from the environment.

The DPM Admin Console should reveal the agents and data sources that were being protected prior to the application of SP1. This completes the restoration but there is still the matter of stabilizing the data sources that DPM is protecting.

As with most application recoveries, a Consistency Check must be run. Since the entire DPM server was restored to a pre-SP1 state, all of the data sources will show inconsistent. A Consistency Check will be required on each data source in the environment and this may take considerable time and storage space to complete.

As the data sources show a Protection Status of ‘OK’, then DPM will continue protecting them based on their original schedules. If there are portions of this process that were not clear or missing, please send us your comments.

Vic Reavis
Support Escalation Engineer
Enterprise Platforms Support

Troubleshooting Agent Deployment in Data Protection Manager 2007 - DCOM

blogdpm — Tue, 19 May 2009 16:28:18 GMT

The DPM agent is a DCOM application - it cannot function correctly without proper DCOM configuration. This section covers the necessary configuration checks to make sure that DCOM is configured correctly.

Non-Clustered Member Servers:

As a rule, DCOM Settings for a working DPM 2007 Agent are evidenced by a lack of problems: You'll need to check Event Viewer, Add\Remove Programs, DCOMCNFG, and WBEMTEST in order to confirm the COM is working.

Event Viewer:

Make sure that there are no VSS or DCOM errors showing up in the event logs on the agent and the DPM server.

Here are some examples of what you might see on your DPM Server if DCOM needs to be checked out....

5/6/2008 8:46:46 AM         1              0              10006
DCOM   N/A
<<DPMserverName>>          2148007941 <<DPM serverName fqdn>>
{C4EBD674-1457-4B79-BE30-B04735AED9D1}

Event Type:        Error
Event Source:      DPM-EM
Event Category:    None
Event ID:          2
Date:              5/8/2008
Time:              9:02:00 AM
User:              N/A
Computer:          <<DPMserverName>>

Creation of recovery points for <<Protected ServerName>> on
<<Protected ServerName fqdn>> have failed.
The last recovery point creation failed for the following
reason: (ID: 3159)

The replica of <<Protected ServerName>> on
<<Protected ServerName fqdn>> is not consistent
with the protected data source. (ID: 30301)

DCOMCNFG:

Open DCOMCNFG, by clicking on Start\Run, and entering ‘DCOMCNFG’. Navigate down to

Console Root\Component Services\Computers\My Computer and open the properties of ‘My Computer’.

Note: If 'My Computer' has a red 'X' by it and the properties cannot be fully displayed, check the MSDTC (Distributed Transaction Coordinator) service to make sure it is running. If it doesn’t start, correct this problem before continuing. If the protected computer is a member server or workstation, try starting it and setting the service to 'Automatic' and rebooting. After logging onto the machine, open DCOMCNFG and 'My Computer' should appear without a red 'X' by it. If the system is a clustered server, make sure the cluster service is running as this will affect the MSDTC service's ability to run. MSDTC doesn’t, however, have to be a clustered resource in order for this to work correctly.

Check also for the existence of 2 DCOM Applications that are installed when the DPM Agent (recall that the DPM Agent is often called the "DPMRA") is installed on a server or workstation. Following are the settings for the DPMRA and WSSCmdletsWrapper DCOM applications.

‘DPM RA’ DCOM Application

Navigate through the "DCOM Config" tree to the DPM RA Service, as below, and select properties.

1. Under 'General', "Authentication Level - Default"
2. Under 'Location', only "Run application on this computer" should be checked
3. Under Security, verify that the "Launch and Activation Permissions" (select "Edit") include the machine account for the DPM Server as shown below.

4. Under Endpoints, leave "… default system protocols …" as the only entry.

5. Under Identity, the radio button "The system account (services only)." should be checked.

WSSCmdletsWrapper

This DCOM application appears under the same tree as above (My Computer / DCOM Config / WSSCmdletsWrapper / Properites). The related application is C:\Program Files\Microsoft Data Protection Manager\DPM\bin\WSSCmdletsWrapper.exe.

1. Under 'General', "Authentication Level - Default"
2. Under 'Location', only "Run application on this computer" should be checked
3. Under Security, you should see

4. Under Endpoints, leave "… default system protocols …" as the only entry.
5. Under Identity, the radio button, "The launching user" should be checked.

If you're concerned that the DCOM permissions have been modified, check the following registry key on both the protected server and the DPM server. There are up to 4 registry values added at the root of the OLE key.

HKLM\Software\Microsoft\Ole – check for the existence of the following value: ‘EnableDCOM’[REG_SZ] = ‘Y’ if not present, or if it is set to ‘N’ – either add the value or change it to ‘Y’. This is the registry storage location which tells if DCOM is enabled or disabled.

To reset the DCOM security, at the OLE registry key, delete all keys except for 'Default' and 'EnableDCOM'. Now reboot the server. When the server comes back up, the DCOM security will be at the default and you will need to open up DCOMCNFG in order to reconfigure it.

NOTE: Please backup the OLE key before you delete it. This will not cause the server to fail to boot but having a copy of the key will allow you to return it to its previous configuration if needed or desired.

The DPM Agent requires Distributed COM to work and does not require COM+ for agent installation or normal operation. Agents can be deployed on to systems that do not have the "Enable network COM+ Access" enabled within Add\Remove Programs.

Local DCOM Settings for DPM Agents are shown below.

1. Check to make sure that DCOM is enabled on the server that is going to be protected by DPM. This can be done in 2 ways. From within the UI, check the following in DCOMCNFG.

Open DCOMCNFG, by clicking on Start\Run, and entering ‘DCOMCNFG’. Navigate down to

Console Root\Component Services\Computers\My Computer and open the properties of ‘My Computer’.

On the "Default Properties" tab, "Enable Distributed COM on this computer" should be checked.

2. Check to make sure that the "Default Authentication Level" is set to "Connect" and “Default Impersonation Level" is set to "Identify".

3. The other option is to check the registry. Look for the key "HKLM\Software\Microsoft\Ole\EnableDCOM = Y"<REG_SZ> – check for the existence of this key and if not present, or if it is set to 'N' – either add the value or change it to 'Y'.

4. Back to the GUI on the Default Protocols tab - confirm that "Connection-oriented TCP\IP" is at the top. Also check the properties for DCOM port range to see if there are any restrictions (by highlighting "Connection-oriented TCP\IP" and selecting properties). Most likely, the screen will be blank, as below.

There are several registry settings that control the DCOM port restriction functionality. All of the named values listed below are located under the

HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc\Internet

registry key. This registry key does not appear in the registry by default and must be created. If you find a need to restrict the DCOM ports, you should add the same port restrictions to both the DPM server and the protected server.

Note: You must reboot your machine any time you make changes to any of the following registry settings in order for them to take effect. Warning: Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall your operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.

NAME TYPE

VALUE

Ports

REG_MULTI_SZ

Specify one port range per line. Example: 3000-4000 5141

DESCRIPTION: One or more port ranges. The options below determine the meaning of this named value.

PortsInternetAvailable REG_SZ "Y" (don't include quotes)

DESCRIPTION: Always set this to "Y".

UseInternetPorts REG_SZ "Y" or "N" (don't include quotes)

DESCRIPTION: If this value is set to "Y", then the Ports named value indicates which ports should be used for DCOM applications. If this value is set to "N", then the Ports named value indicates which ports should NOT be used for DCOM applications.

Examples:

1. Add the Internet key under: HKEY_LOCAL_MACHINE\Software\Microsoft\Rpc

2. Under the Internet key, add the values "Ports" (MULTI_SZ),

"PortsInternetAvailable" (REG_SZ), and "UseInternetPorts" (REG_SZ).

In this example ports 5000 through 5100 inclusive have been arbitrarily selected to help illustrate how the new registry key can be configured. For example, the new registry key appears as follows:

Ports: REG_MULTI_SZ: 5000-5100

PortsInternetAvailable: REG_SZ: Y

UseInternetPorts: REG_SZ: Y

3. Restart the server. All applications that use RPC dynamic port allocation use ports 5000 through 5100, inclusive. In most environments, a minimum of 100 ports should be opened, because several system services rely on these RPC ports to communicate with each other.

You should open up a range of ports above port 5000. Port numbers below 5000 may already be in use by other applications and could cause conflicts with your DCOM application(s). Furthermore, previous experience shows that a minimum of 100 ports should be opened, because several system services rely on these RPC ports to communicate with each other.

Note: The minimum number of ports may differ from computer to computer and depends on the configuration of the computer.

To test and verify connectivity after making this registry change you can utilize the DCOMtest.exe tool. To download the tool and get additional details regarding the use and results you can leverage the following article.

KB259011 “SAMPLE: A Simple DCOM Client Server Test Application”

<http://support.microsoft.com/default.aspx?scid=kb;EN-US;259011>

For additional details on Using Distributed COM with Firewalls you can leverage the following links:

KB154596 “How to configure RPC dynamic port allocation to work with firewalls”

<http://support.microsoft.com/default.aspx?scid=kb;EN-US;154596>

<http://msdn2.microsoft.com/en-us/library/ms809327.aspx>

4. Check the COM Security tab for the following settings. The 'Edit Default' settings do not have to be modified.

On the COM Security tab, under Access Permissions, click Edit Limits.

Verify that the “Distributed COM Users” group is allowed both Local Access and Remote Access permissions. This is the group where the DPM Server's machine account has been added. This group is available after SP1 for Windows Server 2003 is applied, and after Windows XP SP2 has been applied.

after checking "Edit Limits" you'll see

6. On the COM Security tab, under Launch and Activation Permissions, click Edit Limits.

Verify that the Distributed COM Users group is allowed the following permissions:

·    Local Launch
·    Remote Launch
·    Local Activation
·    Remote Activation

Be sure to run secpol.msc and make sure that local security policy is not preventing network access.

1. Check ‘User Rights Assignment’ to confirm that the DPM Server’s machine account
   or authenticated users is specified here.
2. Make sure that “Deny access to this computer from the network” does not include
   the DPM Server's machine account, Everyone, Administrators, or Authenticated Users
   as these will prevent the DPM Server from connecting.

Troubleshooting Security is beyond the scope of this article, but for a good reference, check out:

       909887 Error message when you try to view a Web site that is hosted on Internet
       Information Server 6.0 by using anonymous access: "401.1 Unauthorized: Logon failed"
       http://support.microsoft.com/default.aspx?scid=kb;EN-US;909887

If Agent issues have been preventing consistency checks and/or replication, you may need to now reboot, uninstall the DPMRA, reboot, and reinstall.

Authors:
Victor Reavis
Tom Acker
Microsoft Corporation Enterprise Support

Troubleshooting Agent Deployment in Data Protection Manager 2007 - Networking

blogdpm — Tue, 19 May 2009 16:27:52 GMT

Note: This is the second of a three part series for troubleshooting the DPM RA (Data Protection Manager Remote Agent). Please check out the earlier blog, and the next (all start with the same title).

Network security protocols between the DPM Server and the Agent can directly affect Agent communication as can DNS configuration and registration issues. Check these settings on each server to ensure that there are no network issues blocking the agent and server from communicating with each other.

1. Check SMB (Server Message Block) signing on the DPM and PS (Protected Server) servers and verify the following settings on both servers.

Windows XP and 2003 - local computer Group Policy

Workstation/Client:

Microsoft network client: Digitally sign communications (always) Security Setting: disabled
Microsoft network client: Digitally sign communications (if server agrees) Security Setting: enabled

Server

Microsoft network server: Digitally sign communications (always) Security Setting: disabled
Microsoft network server: Digitally sign communications (if client agrees) Security Setting: disabled

2. Check and make sure that Windows Firewall is disabled on both the DPM and PS servers. If it must be enabled, make sure that the following ports are open. (More information in 947682 - http://support.microsoft.com/kb/947682). Also, if it must be enabled, make sure it is enabled before installing the agent as the DPM installation process automatically configures the firewall exclusions to allow DPM agent communication.

a. 53 UDP
b. 88 TCP\UDP
c. 135 TCP
d. 137 UDP
e. 138 UDP
f. 139 TCP
g. 389 TCP\UDP
h. 5718 TCP (DPM)
i. 5719 TCP (DPM)
j. Add the DPMRA application to the exclusion list.

3. Make sure that there are no firewalls in between the DPM and protected servers and if there are, make sure the exceptions specified above have been applied.

4. If a Netlogon Event error is displayed in the System Event log or the below error in the DPM Administrator’s Console, make sure that the DPM Agent’s machine account exists in the domain and has not been reset. On the DPM Agent computer, check the System Event log for an Event 5721 from Netlogon indicating what the account problem is.

If the machine account has been deleted, correct this by recreating the account and disjoining and rejoining the computer to the domain.
If the machine account has been reset, then SID in the account will match the machine's SID and you can use NetDOM or NLTEST to reset the machine account's secure connection to the DCs.

Data Protection Manager Error ID: 318

Error: The agent operation failed because DPM was unable to identify the computer account for: <FQDN for agent machine>

Detailed Error Code: No mapping between account names and security IDs was done.

Recommended Action: Verify that both <FQDN> and the domain controller are responding. Then in Microsoft Management Console (MMC), open the Group Policy Object Editor snap-in for the local computer and verify the local DNS client settings in Local Computer Policy\Computer Configuration\Administrative Templates\Network\DNS Client.

5. If DCOM appears to be OK after checking WBEMTEST and DCOM sections (to follow, below) and we are still seeing what appears to be network communications issues, try pinging the DPM server from the protected server and vice versa by FQDN as well as IP. If this works, check to see if there have been any manual updates to the HOST file on the machines in question. Also check, using NSLOOKUP, to ensure the protected server is dynamically updating the DNS servers properly as this will also cause agent installation\communication to fail.

WBEMTEST:

WBEMTEST is a tool we can use to test connectivity between the DPM Server and the DPM Agent system. We will use WBEMTEST to test our DCOM connectivity.

Logon the DPM server using the same credentials you are using to deploy the DPM File agents. Try to connect using WBEMTEST from the DPM Server to the Server you plan on installing the DPM Agent onto. If you received the following error, please verify that the DCOM settings are correct.

Number: 0x80070005
Facility: Win32
Description: Access is denied

To test the DCOM connectivity via WBEMTEST, click on 'Start\Run' and type 'wbemtest' and hit enter. The following screen appears.

Click on the "Connect" button and the following screen will appear with 'root\default' in the 'Namespace' field. Type in the name of the DPM Agent machine and specify the 'root\default' namespace to connect to.

The UNC-style connection will initiate a DCOM connection from the DPM Server (local) to the DPM Agent Server (remote) and try to open up the 'default' namespace. If this fails, then there are still DCOM issues on the system.

A working example appears below.

Once a connection has been made, the button appear 'live' as in the screen shot above. Now click on the 'Enum Classes…' button at the top of the left-hand column.

Once this screen appears, you can specify a class name if you know one but the easiest confirmation is done by selecting the 'Recursive' button and clicking on OK. This will show all of the top-level classes in the Default namespace. Once you have this information, you have confirmed that DCOM works. The below screen shot is an example of what a successful recursive query will return.

Cluster Nodes:

The Cluster Service must be running in order for the DPM Agent installation to proceed. Without the Cluster service running, MSDTC will not be accessible and this will affect the agent installation of DCOM. There doesn’t need to be an MSDTC resource in the cluster for the DPM Agent installation to work.

All other settings for local security and DCOM are the same as the Non-Clustered Member Server settings above.

Author:

Victor Reavis
Support Engineer
Microsoft

Troubleshooting Agent Deployment in Data Protection Manager 2007

blogdpm — Tue, 19 May 2009 16:26:38 GMT

Microsoft’s Data Protection Manager (DPM) version 2007 must have an agent installed on any server or workstation that it is going to protect. The installation of the DPM agent requires contact with many different components both locally and across the network. In this and the next two blogs, we will try to cover as thoroughly as possible, all of the local and remote contingencies that must be met in order for the DPM agent to be installed successfully and establish communication with the DPM Server.

These will include the specifics regarding Manual Agent Installation, Local Security on the DPM Agent, Network configuration, WBEMTEST, and DCOM configuration settings in a attempt to provide you with the most common causes of why DPM Agents either will not install or are not able to communicate with the DPM Server after installation. In this blog we'll cover:

Manual Agent Installation
Local Security on the DPM Agent
Domain Controller requirements

Manual Agent Installation: When working on a DPM Agent Installation issue, consider some of the following tests to see where the problem may reside.

1. Try installing the agent manually on the server to be protected and try pushing it from the DPM Server. Do both error out or does one succeed when the other doesn't? If the manual agent installation succeeds and the push fails, then there is likely a problem on the network or with network communication between the DPM Server and the Protected Server or some necessary configuration in the environment with AD or Name Resolution (DNS) that is missing.

2. Try to add the agent server to the DPM Server using both SetDPMServer* as well as the PowerShell script (Attach-ProductionServer.ps1) on the DPM Server.

The SetDPMServer’s syntax is a follows:

SetDPMServer –dpmServerName <DPM Server name>

for example,

SetDPMServer –dpmServerName DPM_Server_01

*Note: The SetDPMServer tool is found on a DPM Agent under the ?:\Program Files\Microsoft Data Protection Manager\DPM\bin\ folder and it is run locally on the system.

The PowerShell script’s syntax below is followed by an example command.

Syntax:

Attach-ProductionServer.ps1 <DPM server name> <production server name> <user name > <password > < domain>

Example:

Attach-ProductionServer.ps1 dpmserver SQLProd1 Admin_VR P@ssw0rd1! Contoso

Use the above power shell script to attach a manually installed agent on a protected server to the DPM Server. Once complete, refresh the agent display in the DPM Console to see if the agent is showing healthy or if an error appears.

3. Disable everything non-essential using MSConfig to see if this will get around the installation issue. This would include anything 3^rd party under the ‘Services’ or ‘Startup’ tabs. Clean the agent off of the server and attempt the installation again after the server is rebooted. The agent should be uninstalled using Add\Remove Programs.

4. Remove leftover DPM keys in the registry after removing DPM client using Add\Remove programs. Primarily, the DPMRA keys should be removed. A simple search through the registry should reveal the following locations:

HKLM\Software\Microsoft\Microsoft Data Protection Manager

HKLM\System\CurrentControlSet\Services\DPM** (DPMRA, DPMLA, DpmWriter)

After cleaning up the registry, also delete the "DPMRADmTrustedMachines" and "DPMRADCOMTrustedMachines" groups and remove the DPM server's machine name from the "Distributed COM Users" group. These groups are created during the DPM Agent installation and the DPM Server’s machine account is added to the "Distributed COM Users" group during the agent’s installation. If the local groups cannot be created or any of the three groups populated with the DPM Server’s machine account, then the agent cannot be managed by the DPM Server.

Local Security: In this section of the DPM Agent installation, we discuss the local security modifications that need to take place in order for the DPM agent’s installation to complete successfully and allow the DPM Server to manage the agent. We will discuss the local security settings on non-Domain Controllers first as this is the foundation from which we will make our modifications when discussing how the agent installation is different on Domain Controllers and Failover Cluster nodes.

Non-Domain Controllers:

The DPM Agent installation adds the following locally to the system.

1. DPMRADCOMTrustedMachines local group with the DPM Server’s machine account as the only member.

2. DPMRADmTrustedMachines local group with the DPM Server’s machine account as the only member.

3. The DPM Server’s machine account is added to the Distributed COM Users group.

Check the following settings on the machine where the DPM agent is being installed.

4. The ADMIN$ share on the Protected Machine must be accessible from the DPM Server using the account that you are planning to install the agent with.

5. Make sure that the Local Policy "Access this computer from the network" includes the <DPM Server Machine Account> account and\or "Authenticated Users"

This user right determines which users and groups are allowed to connect to the computer over the network. Terminal Services are not affected by this user right.

Default:

On workstations and servers:

                Administrators
                Backup Operators
                Power Users
                Users
     Contoso\DPMServer           < - - Must be added manually

On domain controllers:

                Administrators
                Authenticated Users
     Contoso\DPMServer           < - - Must be added manually

6. Make sure that the Local Policy "Deny access to this computer from the network" does not include the DPM Server's machine account, Everyone, Administrators, or Authenticated Users as these will prevent the DPM Server from connecting.

7. Delete, if it already exists, the leftover ‘Microsoft Data Protection Manager’ folder under C:\Program Files. If you cannot delete the folder, use a tool like Handle.exe or Process Explorer to see what has it locked.

8. Confirm that the PageFile is on the C:\ drive. Not a DPM requirement but has been seen on problem machines. For example, the agent install logs might show that the installation is trying to run on another drive on the system like D:\. After each failed attempt, there is a folder left behind with an alpha-numeric string but no indication that it is DPM related until you browse it’s contents.

9. Run the ‘Set’ command to see if the machine is logged into the domain. Log into the domain if you are not already. Specifically, check the ‘USERDOMAIN=’ value to confirm it contains a domain name and not the local system’s name.

Domain Controllers

Since there are no local accounts or groups on Domain Controllers, the location of the 'Distributed COM Users' group is found under 'Active Directory Users and Computers' snap-in. Look under the 'Built-in' node for this group. At the domain level, the machine account for the DPM Server must be added in order for the agent to be installed on Domain Controllers.

DPMRADCOMTrustedMachines and DPMRADmTrustedMachines local groups cannot exist on any Domain Controllers because they don't have a local accounts database. Manually create these groups in the domain with a "Domain Local\Security Group" context and add the machine accounts for any DPM Servers that will manage the agents. It is recommended to only specify 1 DPM Server and have that DPM server protect all Domain Controllers to avoid agent issues.

NOTE: The default when you create these groups will be to use a Global "Group Scope". The "Group Scope" must be changed to Domain local for this.

Next, we'll discuss troubleshooting Networking and WBEMTEST followed by DCOM.

Author:

Victor Reavis
Support Engineer
Microsoft Enterprise Support

Technorati Tags: DPM,Data Protection Manager

Introduction to SharePoint Search Indexes for DPM Administrators

blogdpm — Tue, 12 May 2009 15:40:07 GMT

This blog introduces the basics of SharePoint Search capabilities to DPM Administrators. Initially, it may be a bit confusing as to why a DPM blog would contain information about how to setup and configure another technology’s software. In protecting this data using DPM, it is necessary to have an understanding of how the protected application is installed and configured. This is especially true with regards to Search Index database protection.

By the conclusion of this short series of blogs, you will have a greater understanding of why knowing a bit about the applications that DPM protects helps in their protection, recovery, and maintenance.

Why 2 versions of Search

Since DPM offers the capability to protect both WSS Search and MOSS Search, let’s take a moment to understand the difference before we dive into the set up and configuration aspects.

First, let’s discuss the basics of what a Search Index server used for. This is the same principal as how the Internet works. Websites are “crawled” (queried for their contents) and a reference to their content is then stored in a database. Think of this as you would an index to a book. From a SharePoint perspective, this allows user to location content in the farm without knowing where the content actually resides.

“Office SharePoint Server 2007” provides two search services: “Office SharePoint Server Search” and “Windows SharePoint Services Help Search”. Each of these services can be used to crawl, index, and query content, and each service uses a separate index.

The “Office SharePoint Server Search” service is based on the search service that is provided with earlier versions of “SharePoint Products & Technologies”, but with many improvements. You should use the “Office SharePoint Server Search” service to crawl and index all content that you want to be searchable (other than the Help system).

The “Windows SharePoint Services Help Search” service is the same service provided by “Windows SharePoint Services 3.0”, although in “Windows SharePoint Services 3.0” it is called the “Windows SharePoint Services Search” service. “Windows SharePoint Services 3.0” uses this service to index site content, index “Help” content, and service queries.

Installing a Search Index Server

The installation of a server for Search is the same as with any other SharePoint server. Use the “Advanced” option during installation and add it to an existing farm. The piece that defines the server as a Search server is found in the “Central Administration” website under “Operations” and “Services on Server”

An example of this screen is shown below for your convenience.

After clicking on the “Start” action, a wizard is displayed where you will need to specify some basic configuration information. In this wizard, you will make selections on which WFE’s (Web Front-End server) will be used to crawl the content of sites in the SharePoint farm and add their content references to its index.

As part of the configuration, you will also need to create a database for the index references to be stored. This is also done from within the Central Administration website.

Below is a screenshot of the information that must be specified when creating the database. When creating the database, be sure to give it a name that makes it easy to identify its purpose.

With the content database created, we need to look at the creation of a Shared Services Provider.

Shared Services Provider (SSP) Configuration

Once the services have been configured on the Search Index server and are running, you are down to the last step. An SSP (Shared Services Provider) must be created as this is the SharePoint object that has the crawling functionality in it.

We will start by creating the Shared Services Provider by clicking on the Shared Services Administration link on the left side from within the Central Administration website’s main page.

Begin by clicking on the New SSP link as seen below by the pointer.

This opens a new page where you will specify the configuration information needed for SharePoint to create the provider. A database is also needed for this so make sure that the database name is clear as to its purpose. Once the necessary information has been provided, click on the “OK” button at the bottom to allow SharePoint to create the provider.

Once complete, you should see a page like the following indicating that you have successfully created a Shared Services Provider.

Now, we need to figure out how to crawl the sites in the farm.

SSP Crawl Configuration

When the Shared Services Administration page opens for this SSP, click on the Search administration link under the Search section to begin the crawl configuration.

When the Search Administration window appears, notice that the Items in index value is ‘0’ which is expected as this SSP was just set up and has not yet been configured. Under the Crawling section on the left, click on the Content sources link to start the configuration.

This will bring up the Manage Content Sources window.

After the Manage Content Sources window appears, there should only be a single entry in the list titled Local Office SharePoint Server sites. Click on this link as this is what will need to be configured in order to make this SSP useful.

At the top of the configuration page titled Edit Content Source, you have the option of changing the name to something more suitable. This is an optional entry.

If there are other site addresses that you would like this SSP to crawl, enter them in the box as seen below. If you are unsure of the URLs of the SharePoint sites, there is an alternate location that we will discuss in a few steps that will set this up for you. You will only need to select radio buttons based on a list of sites.

Here, the settings begin to get more impactful. In the Crawl Settings section, choose one of the two radio buttons which essentially allow you to filter on whether the content is SharePoint in nature or not. Choosing the Crawl everything… radio button allows the crawl to capture the maximum amount of data but also opens up the searches to additional content that you may not be expecting. For a test environment, this is the best solution as long as none of your SharePoint sites contain external site references on the Internet as the crawl will catalog the Internet data as well.

The last settings to make are for scheduling when the crawls will take place on the sites selected. Selecting the Create schedule links under the Full Crawl and Incremental Crawl sections will allow for a modest configuration schedule.

Each Create schedule link will open the following window offering multiple types with multiple settings for each. In a lab-style environment, these can be quite lenient with longer intervals. If you are testing or working in a rapidly updating environment, then a shorter interval is recommended.

Click on OK to accept the schedule you have configured and then fill in the Start full crawl of this content source checkbox so that when you click OK, the initial crawl will begin.

Depending upon how much configuration and modification you have done to the sites specified in the crawl list, the crawl should run in just a few minutes. The Status field should show Crawling Full when the page is initially drawn. You can monitor the page or you can leave it and continue with your SharePoint work. Once the initial crawl is complete however a Search site should be setup, if it has not already been added, so that you can test the index information for accuracy.

Creating Crawl Rules

A short configuration step to take is to include the paths and authentication accounts for crawling. To reopen the crawl rules, click on the Crawl rules link under the Crawling section on the left side of the SSP’s Search Administration page.

Since this is a newly created SSP, there will be no rules. Click on the New Crawl Rule link to create rules for this SSP.

There are 3 sections to be configured here and the following shows a test configuration that works. For simplicity, use these settings and click on OK to complete the configuration.

The Manage Crawl Rules page should return pretty quickly to let you know what configuration has been made. The crawl that you ran should be done by now as well.

Working under the premise that the crawl has been completed, a return to the Search Administration site should display entries like the following. Observe that the Items in index field now has a non-zero value indicating that there are entries in the index.

To supplement the high-level overview of the steps covered here, a video has been provided that will guide you from start to finish.

Video

Vic Reavis
Support Escalation Engineer
Microsoft Enterprise Platforms Support