Video Screencast Help
Symantec to Separate Into Two Focused, Industry-Leading Technology Companies. Learn more.

Need the MSI Property value for password protected unattended install

Created: 27 Mar 2013 | 9 comments

We are trying to push an unattended uninstall-upgrade of our SEP clients (going from v11 to v12.1RU2).  Like most, our client uninstall is password protected.  I assume there is an MSI property value one can set the password equal to, in order to send it to the MSI uninstall command.  Does anyone know what that property is?  Should like something like this.  I wanted to ask here first before cracking open the msi with admin studio and digging around for it.

msiexec /X{GUID} /Q property=password

 

Operating Systems:

Comments 9 CommentsJump to latest comment

.Brian's picture

I don't believe this is possible. per this KB article:

How to uninstall Symantec Endpoint Protection (SEP) client silently using the command line

Article:TECH105827  |  Created: 2008-01-09  |  Updated: 2010-08-13  |  Article URL http://www.symantec.com/docs/TECH105827

 

Considerations if an uninstall password is in place
If you set a password for client uninstallation, you cannot uninstall the client silently. Clients with an uninstall password are prompted for the password, which must be entered manually. To uninstall the client silently, disable the password.

Please click the "Mark as solution" link at bottom left on the post that best answers your question. This will benefit admins looking for a solution to the same problem.

SMLatCST's picture

As Brian has stated ("Thumbs Up" BTW), there's no MSI switch for providing the uninstall password, so if you're planning to remove SEP across the board, then it seems like you'll have to disable the password protection first to be able to automate it all.

If this is purely for an upgrade however, you can use SEP's inbuilt mechanisms as per the below article.  As the whole process is managed by SEP, it bypasses the password requirement:

http://www.symantec.com/docs/TECH166317

Rafeeq's picture

There are two keys which you need to take care if its 11.X

once thats done, you can run the msixec.exe / q

Check this article.

https://www-secure.symantec.com/connect/articles/h...

limnos's picture

So, if I disable the password and service protection in the general settings for all workstation locations, that should then replicate out to all clients next time they do a policy update, correct?  Also, correct if I'm wrong here, but the internal update tool doesn't have bandwidth throttling, so our low bandwidth sites (which we have many), will be very problematic.  We have GUPS at all those locations, does it cache it at the GUP's and then distribute the new client from there?

Lastly, being also an advanced software packager, I assume that there must be a component in the msi that checks "something" on the local machine to see if there is a password set or not.  I know that, if the SMC service is not protected, you can stop that service and delete a particular reg key to thwart the password protection, but I will not share that key here on the open forum, you SEP folks know which one I'm talking about.  I assume that key is what the msi uninstaller is looking for to determine if it can keep running or prompt for a password.  But, we protected our SEP service for just that reason, so I can't just shut that off with a script and delete the reg key to get around it.

SMLatCST's picture

As far as the native upgrader goes, you are correct that GUPs do not help with the upgrade packages.  Instead, for remote sites, you can employ the below articles to copy across a package to the remote site before the upgrade, then point the clients at that local copy:

http://www.symantec.com/docs/TECH106181
http://www.symantec.com/docs/TECH97406
http://www.symantec.com/docs/TECH96873

Once the client package is served from another web server (IIS) you could even add throttling if you wanted, though it shouldn't be unnecessary if you've copied the package to a lcoation closer to the clients.

Regarding MSI, i wouldn't get too caught up in it.  With the SEP install, it's only used to kick off symantec's own installer which performs a side-by-side install of the new client, which only swaps files round at reboot (in SEP12.1 and later).

Rafeeq's picture

GuP can update only definitions and not policies.

You can share the key offline :) not the one I specified in the above link?

A. Wesker's picture

FYI,

The registry keys still exist on SEP 12.1 :-P

Notice that if you use Auto-Upgrade to deploy your machines, you'll definitely need to deactivate password protection for uninstall and unload SEP otherwise when your clients will retrieve the package and try to run it, the setup.exe and msiexec executed locally on the machines will never end and the install will never be completed (even if you reboot your machine, it will have the same behavior).

On the SEP_inst log you will see anyway on the log something like "Checking Uninstall password" ... and it will stay like that forever (seen tested and approved lol ^^).

 

Kind Regards,

A. Wesker

limnos's picture

Yeah, thanks, I figured that. I went in an deactivated the security for the uninstall and the service protection for all locations, until the deployment is completed. I like the remote web server idea, if we had one to use! LOL. We have GUPS that are also LANDesk SNR's, we are thinking of making our SNR's LANDesk preferred servers, which would then have a http: location on them at that point, which I could leverage for this. But, that's not in the scope of this upgrade project. I am going to try the direct upgrade from the server on the devices here in the main office where there are no bandwidth issues.