Silent registry merge

[HereFishyFishy]

I have a logon.reg file that needs to be merged everytime a user logs onto a machine.

I've tried placing the logon.reg file in Group Policy under "Run these programs at user logon" but my users receive the "are you sure you want to add the information in ... to the registry?"

So I did some research and found out I could create a logon batch file to start the import with the following "regedit /s logon.reg" However, when a normal user logs on they don't have permission to change the registry so as the cmd box pops up I can see "access denied" scroll through and the merge doesn't happen.

Is there something I can add in the logon.reg file to automatically click yes instead of prompting my users?

[nmX.Memnoch]

REGEDIT /S <path>\logon.reg

[HereFishyFishy]

As I said in my original post, I've tried "regedit /s logon.reg" and the users don't have permission to change the registry. I need a way to either run the batch file as an administrator or I need a way for the .reg file itself to "click" yes.

[cluberti]

runas command?

You may also want to add the registry keys using something more secure, like an encrypted VBS file. Otherwise, the admin username and password will be in the batch file.

[nmX.Memnoch]

As I said in my original post, I've tried "regedit /s logon.reg"

Sorry...skipped right past that part.

and the users don't have permission to change the registry.

What keys/values are you trying to change? Are they HKLM, HKCU, software specific, policy settings, etc?

[HereFishyFishy]

Thanks, I'll look into the VB scripting since putting the admin password out there unencrypted is not an option.

The overall problem, and the reason I need to load this registry key everytime a user logs on traces back to Symantec AntiVirus. My corp. is running 10.0 and everyone was receiving DoScan.exe errors. We tried running the Symantec service on all of the machines as admin, but it kept dropping the logon priveledges for the service and knew that shouldn't be the final fix. So I found out Symantec has a RemoveStartScan.reg file that can be run to stop the scans at startup, but it has to be run everytime a user logs on. This got rid of the DoScan.exe errors, but introduced the registry merge popup I stated above. I heard 10.1 fixes this solution, but that costs $$

The RemoveStartScan.reg changes HKCU settings.

[cluberti]

You could always look into creating your own custom .adm templates in AD, and just put the registry changes in there - that will work too.

[nmX.Memnoch]

The overall problem, and the reason I need to load this registry key everytime a user logs on traces back to Symantec AntiVirus. My corp. is running 10.0 and everyone was receiving DoScan.exe errors. We tried running the Symantec service on all of the machines as admin, but it kept dropping the logon priveledges for the service and knew that shouldn't be the final fix. So I found out Symantec has a RemoveStartScan.reg file that can be run to stop the scans at startup, but it has to be run everytime a user logs on. This got rid of the DoScan.exe errors, but introduced the registry merge popup I stated above. I heard 10.1 fixes this solution, but that costs $$

'Nuff said...we're having our own set of problems with SAV 10.0.0 and 10.0.1 on WinXP (works fine on Win2000). The problems we're having have Symantec completely befuddled. I've heard that 10.1 will be out pretty soon though and should fix a lot of problems.

The RemoveStartScan.reg changes HKCU settings.

I downloaded RemoveStartScan.reg and checked the keys it attempts to remove/update. The default permissions should allow for the user to change the settings within those keys. Have y'all set any policies to prevent the users from running registry editing applications (GPO > User Configuration > Administrative Templates > System > Prevent access to registry editing tools)?

[cluberti]

What problems are you seeing with 10.0 and 10.0.1? I see quite a few every day (which are usually resolved by upgrading to 10.0.2) - I may be able to assist.

[HereFishyFishy]

mmx - Yes, we have the registry editors disabled. I found a little program called "regpol" that claims it can merge the registry files no matter what the permissions, but I'm a little skeptical as there's little to no documentation on this application.

cluberti - The only problems we really have with SAV 10.0.0.359 are the DoScan.exe errors everytime a user logs on and an occasional RtvScan.exe error, which is what leads me to the silent merge of the RemoveStartScan.exe

[nmX.Memnoch]

mmx - Yes, we have the registry editors disabled.

That's why the "REGEDIT /S LOGON.REG" is failing. Any particular reason y'all are disabling that? That option has the potential to kill a lot of options you have available to you with logon scripts in the future. KiXtart has registry functions as well that may bypass this setting though...I'd have to try it just to verify for you, but I'm willing to if you want. VBS may also bypass this. I personally prefer KiX, but that's what I got started with.

What problems are you seeing with 10.0 and 10.0.1? I see quite a few every day (which are usually resolved by upgrading to 10.0.2) - I may be able to assist.

I know it's a permissions thing but I haven't been able to nail down exactly what it is yet. Let me see if I can explain this correctly...

Our previous version was 9.0.2.1000. The office that controls our SAV servers/clients was directed to upgrade to 10.0.1.1007. For some reason they decided to create an SMS package to push 10.0.1.1000 with the 1007 patch instead of using the SSC to push 10.0.1.1000 and then an SMS package for the 1007 patch (at least that's what I would've done...or just patched the install point with the 1007 MSP...either way would've been better).

This seemed to have worked ok until we started getting calls from some of our users. Basically when they right click on anything that activates the explorer.exe context menu (My Computer, Create New Folder, etc) the Microsoft Installer acts like it's attempting to finish the SAV install. This only happens if they only have "User" or "Power User" (which we don't use) permissions. If they have Admin permissions (which only my office does), it doesn't happen. It also doesn't happen if the machine was installed fresh with 10.0.1.1007, only if it was upgraded from 9.0.2.1000.

We're also being told that we're the only unit* seeing this problem. However, I suspect this is because a lot of other administrators on base give their users Admin privs because they've been told "XYZ application requires admin privs to work"...when in actuality all that's required is changing NTFS permissions on a few specific files so that a "User" has write access to them. We've taken those steps to prevent "having" to make our users Admins on their workstations. It's been my experience that most of our "in-house" developers don't understand permissions outside of "Admin", "Power User" or "User"...which is really sad, but that's a completely different discussion.

* I work on an Air Force base.

Edited March 2, 2006 by nmX.Memnoch