An important update of Process Monitor was released couple of a days ago:
As you may know, we can use two functions with completely opposite names to open registry key: RegCreateKeyEx and RegOpenKeyEx. When you use RegCreateKeyEx, it creates registry key if it’s non-existed, but just opens it if key exists. RegCreateKeyEx writes which operation (create or open) it’s performed into a separate variable.
RegOpenKeyEx cannot create registry keys and returns error if key doesn’t exist.
Before this release there were no way to determine what operation exactly RegCreateKeyEx perform. “Granted Access” property for execution of that function always contained “Read/Write” value.
From this last update, Process Monitor finally can show you what RegCreateKeyEx does. There is no “Granted Access” property for RegCreateKey operation anymore, it was replaced with new “Disposition” property. “Disposition” may contains following strings:
REG_CREATE_NEW_KEY – if new registry key was created.
REG_OPENED_EXISTING_KEY – if RegCreateKeyEx just opened previously existed key.
“Desired Access” property still contains “Read/Write” value, because we cannot predict which action RegCreateKeyEx will do.
Using this new feature, you can separate RegCreateKeyEx calls: just add new condition into Process Monitor’s filter with following parameters:
Column – “Detail”
Relation – “contains”
Value – “REG_CREATE_NEW_KEY” or “REG_OPENED_EXISTING_KEY”
Action – “Include”
You have one secondary DPM-server (DPM3) and 2 primary connected to it (DPM1 and DPM2). You have a server (PS1) protected by DPM1 and DPM3. You decide to move protection of PS1 from DPM1 to DPM2. You stop protection of PS1 at DPM1 and DPM3. You connect PS1 to DPM2. You wait until first replica is created, then you try to add PS1 back to DPM3 but from DPM2 this time.
In that case you cannot see PS1 at DPM3 in the list of data sources protected by DPM2.
This happens because each protected server has a single record in a table of protected servers at DPM configuration database. One of the attributes of this record is an ID of DPM server protecting that data source. Since secondary DPM knows nothing about you moving data sources between primary servers, it doesn’t update that record with an ID of a new primary DPM server.
You can fix this by manually updating DPMServerId attribute of migrated protected server with an ID of new primary DPM server.
WARNING! This scenario IS NOT supported by Microsoft. Use instructions below at one’s own risk, except and only when you are specifically instructed by Microsoft technical support specialist to do this.
Be sure to backup your DPMDB database before run any T-SQL command!
- Connect to DPMDB of your secondary server (You can find more about it here).
- Get a list of DPM-servers and their IDs:
SELECT ServerId, ServerName, DPMServerId FROM [dbo].[tbl_AM_Server] WHERE IsDPM = 1
- Write down IDs of DPM1 (<OLD-ID>) and DPM2 (<NEW-ID>).
- Determine which primary DPM-server protects PS1 according to the knowledge of DPM3:
SELECT DPMServerId FROM [dbo].[tbl_AM_Server] WHERE ServerName = '<Protected Server's FQDN>'
- Make sure it equals <OLD-ID>, otherwise this instruction is not for you — contact Microsoft Support instead.
- Update protected server record with ID of new primary server:
UPDATE [dbo].[tbl_AM_Server] SET DPMServerId = '<NEW-ID>' WHERE ServerName = '<Protected Server's FQDN>'
- Run new/modify protection group master and press “Clear cache” button.
- You are now able to protect moved resource at secondary DPM again.
- Never ever move protected servers between primary DPMs connected to the same secondary server, since it is NOT supported by Microsoft.