Ive run into this issue multiple times now. Here is the situation:
At this point, if Altiris does its thing correctly and merges the new record for the RS server with the old one (retaining the old GUID), you will not be able to add the rebuilt RS server to the cluster as Altiris still thinks the original server is still servicing that cluster (basically, since the new RS server takes assumes the old GUID, Altiris thinks that nothing has changed and that the old server is still out there servicing the cluster). You can verify this is the case by opening the “Recovery Solution Server Uninstall” section on the Notification Server console. In there you will see the server that you rebuilt as available to uninstall (even though the rebuilt server doesnt have the RS server installed on it yet).
This leaves you with a unique situation…you need to remove the RS server record from the cluster to make Altiris think there are no RS servers servicing that cluster so that you can install a new RS server into that cluster (the rebuilt server). This can be accomplished by removing a row in the Notification Server database:

At this point, you will now notice that this server no longer shows up in the “Recovery Solution Server Uninstall” area in the NS console. You now will be able to add your rebuilt RS server to the cluster.
Microsoft has just released DPM 2007 SP1 (Version 2.0.8793.0…released on 12/19/2008). You can find the update here along with other information pertaining to the update. Notable fixes/changes in SP1 include:
…along with a slew of other stuff. NOTE: This update will require a reboot of your DPM server and protected clients. Clients can continue backing up normally without a reboot (however the agents MUST BE UPDATED before snapshots can continue), however you should schedule time to perform this soon after updating your agents to avoid issues.
One of the most exciting features of SP1 is direct protection of Hyper-V. Here is a video from TechNet discussing this particular feature:
DPM 2007 SP1 — Protecting Hyper-V
Tags: DPM
Microsoft recently released this Technet article outlining the DPM 2007 alerts and typical resolution procedures. Very handy if you run across an error that you haven’t seen before…this will at least get you pointed in the right direction. You can find the health model here. Here are a few of the resolutions that may be useful:
Tags: DPM
When protecting a Data Source in DPM, you have the option to define your own Replica Volume and Recovery Point Volume sizes or to use the default sizes determined by DPM. Typically, the default sizes provide significant room for growth without gross overallocation of resources (though I tend to find they allocate more space than necessary…I prefer to manually allocate slightly more than the Data Source size and run an “autogrow” script to thin-provision resources. You can find out how to autogrow space here). Below are the algorithms used by DPM to determine how much space to allocate to a Data Source.
Replica volume
For files: (Data source size x 3) / 2 For Exchange data: Data source size x (1 + log change) / (alert threshold - .05) <strong>Note: </strong>Log change is assumed to be 6%. Alert threshold typically 90%. For SQL Server data: Data source size x (1 + log change) / (alert threshold - .05) <strong>Note: </strong>Log change is assumed to be 6%. Alert threshold typically 90%. For Windows SharePoint Services data: Total size of all databases/ (alert threshold - .05) <strong>Note: </strong>Log change is assumed to be 10%. Alert threshold typically 90%. For Virtual Server data: Data source size x 1.5 For system state: (Data source size x 3) / 2 <strong>Note:</strong> Data source size is assumed to be 1GB for Windows 2003 and 10GB for Windows 2008
Recovery point volume
For files: (Data source size x retention range in days x 2) / 100 + 1600 MB <strong>Note: </strong>Retention range is assumed to be 5 For Exchange data: 4.0 x retention range in days x log change x data source size + 1600 MB <strong>Note: </strong>Log change is assumed to be 6% and retention range is assumed to be 5 For SQL Server data: 2.5 x retention range in days x log change x data source size + 1600 MB <strong>Note: </strong>Log change is assumed to be 6% and retention range is assumed to be 5 For Windows SharePoint Services data: 1.5 x retention range in days x log change x total size of all databases + 1600 MB <strong>Note: </strong>Log change is assumed to be 10% and retention range is assumed to be 5 For Virtual Server data: (Data source size x retention range in days x 0.02) + 1600 MB <strong>Note: </strong>Retention range is assumed to be 5 For system state: (Data source size x retention range in days x 2) / 100 + 1600 MB <strong>Note: </strong>Retention range is assumed to be 5
Change journal (for file protection only)
300MB stored on each volume on the protected server
When you are creating a Protection Group (or adding a Data Source to an existing Protection Group), in the modify disk allocation dialog box, these are the algorithms that are used to determine the initial disk allocation based on the volume that the Data Source is on. To apply these algorithms to the actual Data Source, click the calculate button and DPM will poll the client and determine the actual Data Source allocation based on that particular Data Source size and its corresponding formula (which can take a while).
Keep in mind that once you allocation space to a Data Source and commit the settings, you cannot decrease the space allocated. The only way to remove space from a Data Source is to remove protection for it and then setup protection again.
Tags: DPM
Interesting video discussing changes with Veritas (Symantec) Netbackup 6.5.2 (which is out), 6.5.3 (which is greatly anticipated…at least by me) and where the product is headed.
Tags: Netbackup