Database Profiles disappear from registry

We have an odd and very frustrating problem. One of our schedulers lose their database profiles settings from the registry every now and then.
When this happens the situations is reset to the situation existing at the moment we first installed the scheduler. All the new database profiles we added in the meantime are gone.

We now have a reg file with the complete database profiles listed. And everytime the problem occurs we restore the registry by importing this reg file. This is a fix, but we urgently need a permanent solution.

Your description sounds like you are fighting Windows Vista/7/2008 security issues - namely roaming profiles and registry virtualization. Whenever you logoff or change login, your settings are gone from the registry. To avoid that, run 24x7 in Run As Administrator mode, or run as a service using some system account, the changes will then stick in the registry.

	SysOp wrote:
	Your description sounds like you are fighting Windows Vista/7/2008 security issues - namely roaming profiles and registry virtualization. Whenever you logoff or change login, your settings are gone from the registry. To avoid that, run 24x7 in Run As Administrator mode, or run as a service using some system account, the changes will then stick in the registry.

Hi,

This is on a Windows server 2003 machine. We are running the scheduler as a service on a specially created user account with administrator rights.

Are you using remote desktop RDP and terminal server to make changes in the settings of an application?

	SysOp wrote:
	Are you using remote desktop RDP and terminal server to make changes in the settings of an application?

We are RDP'ing into the server that is running 24x7.

Today I decided to let sysinternals regmon monitor the 24x7 registry tree. I now see that the proces 24x7.exe is executing DeleteKey and DeleteKeyValues on all the database profile settings. Later on it does an CreateKey, but only for a specific set of profiles.

Please describe step by step how you make database profile changes. Specifically which interface you use for that purpose (GUI, started while the service is running), standalone GUI, web-console, command-line console, scripting or API)?

	SysOp wrote:
	Please describe step by step how you make database profile changes. Specifically which interface you use for that purpose (GUI, started while the service is running), standalone GUI, web-console, command-line console, scripting or API)?

We installed the scheduler about two years ago on a server. We entered the database profiles using the 24x7 application. We allways logon using rdp.

2 months ago we migrated to a new server. We reinstalled 24x7 on the new server and copied the existing .dat file containing the scripts.

We exported the database profiles to a reg file and imported them on the new server. We also added some new database profiles.

The scheduler is somehow restoring the situation existing at the moment of migration: the 'old' database profiles are kept, but the new ones are deleted.

I'm pretty sure you are fighting Windows security, you are likely using different accounts or not doing it right. Whatever you've imported into the registry during migration, you've likely done that using a different user account. Because of RDP, every time you make changes and logoff, the system restores the previous registry state to what you imported in the first place. Most likely, if you make changes directly on the server, they will stick in the registry.

Please see Microsoft documentation describing registry and config file virtualization
You may also want to check this article http://www.brianmadden.com/blogs/brianmadden/archive/2004/07/29/the-windows-registry-in-terminal-server-environments-part-1-of-3.aspx

SysOp wrote:

I'm pretty sure you are fighting Windows security, you are likely using different accounts or not doing it right. Whatever you've imported into the registry during migration, you've likely done that using a different user account. Because of RDP, every time you make changes and logoff, the system restores the previous registry state to what you imported in the first place. Most likely, if you make changes directly on the server, they will stick in the registry.

Please see Microsoft documentation describing registry and config file virtualization
You may also want to check this article http://www.brianmadden.com/blogs/brianmadden/archive/2004/07/29/the-windows-registry-in-terminal-server-environments-part-1-of-3.aspx

I told you in a previous post that I can see the 24x7.exe process deleting and creating database profiles in the registry (using regmon). This is the reason the profiles are disappearing. Can you please explain why this is happening? Your technical staf probably knows why 24x7 deletes the profiles.

Hi,

I believe you have started with wrong assumptions and still sticking to them. Basically you are looking in a wrong place, I don't mean the registry, I mean the cause of the issue.

24x7 does not delete registry entries if you don't explicitly delete database profiles in the settings. It does however use Windows system
functions to SET values. It is Windows that internally does DELETE and ADD, and how it does it depends on your Windows settings (UAC, terminal services, etc...) and your account settings.

The registry monitor is not going to help in this case. I suggest to use quick and easy method for correcting this issue. Login directly to the server as a local admin, restart 24x7 there (not in a terminal session), make the required changes, and I'm pretty sure you will see them stick this time.

If that doesn't work, please open a case with Microsoft, this issue has nothing to do with 24x7 working.

	SysOp wrote:
	Hi, I believe you have started with wrong assumptions and still sticking to them.

With all due respect, but this can be said regarding your answers as well. You started off by hinting towards Windows restore mechanisms. Allthough I pointed out that there is no Windows restore operational on this server and in spite of the fact that it is clearly shown that the process 24x7.exe is deleting the registry entries, you still hold on to Windows as the main suspect.

	SysOp wrote:
	If that doesn't work, please open a case with Microsoft, this issue has nothing to do with 24x7 working.

I am all but satisfied with your help, but we'll leave it here as you clearly have no idea what is going on with your own software.

I don't know what else to tell you and how to convince you that the issue is not in 24x7. I'm quite sure about it.

May I suggest that you try reproducing this on a different system?

	SysOp wrote:
	I don't know what else to tell you and how to convince you that the issue is not in 24x7. I'm quite sure about it. May I suggest that you try reproducing this on a different system?

Let me instead try to convince you that this is most certainly a 24x7 issue.

I have begun to frequently check the registry for the disappearing profiles and when the profiles disappear everybody that is working with the scheduler tells me what he has done. We have now finally isolated the cause:

When users use the "save remote" option while working remotely on scripts the profiles disappear. This has now been reproduced more than 10 times whithout failing.

I also monitored the registry during this testing with regmon and the registry keys are indeed deleted. By the way, there are also other registry keys deleted, but these are succesfully created again afterwards.

Looking forward to your explanation on this matter.

I have some more information:

I have noticed that there is a "remote config" folder in the registry. This folder is populated with a copy of the database profiles and queues on the server. This is done when you use the remote host for the first time. When I delete the connections under "remote config" and then do a "save remote" the database profiles on the server remain.

Of course this is not a solution as I probably need the remote config to be able to run scripts using the remote control. But maybe you can now better pinpoint the problem.

I'm glad you finally started to understand that this is most certainly NOT an issue with 24x7.

When you save to remote server using 24x7 Remote Control, you connect to the server via 24x7 facilities, the Windows terminal server is not in play. That's why you get the registry stuff saved. When you do it via the terminal server (a.k.a RDP), all your changes are virtualized by Windows, which all happens outside of 24x7 control and transparently to 24x7. You close your session, and your changes are gone.

Let's close this issue. This is not caused by 24x7. There are no questions about it. Please follow the instructions we provided earlier.