Software Deployment Question

Cisco Communicator requires local admin first launch?

10/30/2007 11958 views
I am using the vendor MSI to deploy this app.[/align] [/align]When launching Cisco IP Phone Communicator version 2.1.2[/align] [/align]Windows XP standard User Account gets:[/align]

"Unable to initialize Cisco Emergency Responder Service"
[/align]every time before successfully launching the app.[/align] [/align]Cisco's web site confirms the issue and states the application must be launched the first time by an admin account.[/align]
[font="times new roman"]http://www.cisco.com/pcgi-bin/Support/Bugtool/onebug.pl?bugid=CSCef40483
[/align]I have gone through all access denied errors for both file and registry (using filemon, regmon) and granted permissions in every area until I get no more access denied errors logged in either tool, and I still get the error on launch. [/align] [/align]This is not the installation of a windows service.[/align] [/align]If an admin user launches the app once it prompts for a reboot and that error never comes up again for any users.[/align] [/align]Any ideas?[/align]
0 Comments   [ + ] Show comments


Rating comments in this legacy AppDeploy message board thread won't reorder them,
so that the conversation will remain readable.

All Answers


try doing the same by using a Local System Account (LSA). Perform the following task:

1. type cmd in the run command line.
2. use the at command to open another console that will run using the LSA.
3. launch the executable that gives you this error.

if this behaves the same was as for the administrator, then you can always run this executable using the LSA or you can also use the RunAs command and embedd it at the end of the MSI to run this executable. However, I would term it as a very bad approach.

What a pity that Cisco has packaged this MSI and such a clause is included in it... [X(]
All the Best to you dear!!
Answered 10/30/2007 by: matrixtushar
Purple Belt

Thanks Matrixtushar, thats a good tip to try. The only problem with this particular scenario is that on first launch the app starts a wizard which requires input from the user to set up the audio properties. It's after this wizard completes the error comes. When run by the LSA it hangs waiting for user input.
Answered 10/30/2007 by: yumchild
Senior Yellow Belt

Try snapshotting the changes made by the first launch and add those resources to a transform.
If any are located in the userprofile or HKCU make sure that the application repair those on first launch.
Answered 10/30/2007 by: AngelD
Red Belt

a dirty solution would be to write a VBScript that runs in LSA and uses the function SendKey in the shell object to simulate a user click.

I had to do such a workaround in PGP 8.1 Package... [:(]
if you need the script probably i can provide you...
Answered 10/31/2007 by: matrixtushar
Purple Belt

Hi folks,

I have also come across that issue and found it will appear if a user without administrative privileges is logged in at installation time. As we use Altiris (Symantec) Deployment Server for distribution, we perform an auto-log off prior to the install of the package. The same is valid for currently released IPC v7.0.2.x which we currently distribute.
Hope this helps,
Answered 06/17/2009 by: bzajac
Yellow Belt

It didn't matter if the user was logged in or not during the install. The problem is if after the install a non-admin logs in, the initial tasks (audio setup, etc) fail. I tried capturing it, procmon, regmon, etc. I even tried manually giving the standard user admin equiv permissions on the registry and file system without adding to local admins. It acted like it was doing a check for membership of local admins.

I haven't tried the 7.x versions, so they may have fixed it.
Answered 06/17/2009 by: yumchild
Senior Yellow Belt

It acted like it was doing a check for membership of local admins.
In that case; shimming sound like the solution to this.
Answered 06/17/2009 by: AngelD
Red Belt

This website uses cookies. By continuing to use this site and/or clicking the "Accept" button you are providing consent Quest Software and its affiliates do NOT sell the Personal Data you provide to us either when you register on our websites or when you do business with us. For more information about our Privacy Policy and our data protection efforts, please visit GDPR-HQ