Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations strongm on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Registering .dll for all users help

Status
Not open for further replies.

keybrdcowboy

IS-IT--Management
Aug 31, 2004
96
US
Hi...

I have a script that runs as a computer startup script. The script runs an msi file that installs a piece of software, and then edits a registry entry and runs the regsrv32 command to register two dlls.

The software installs fine, and the registry edits are made, however the dll registering doesn't appear to be working correctly. The software is an outlook add in, and it all works fine up to a point. When I manually register those two dlls (or edit the script to do nothing but register the dlls) everything works fine. However, relying on everything to occur during the computer startup script section, it doesn't work. The program installs, but certain parts of it don't work. Once those dlls get registered, everything works.

I was hoping someone would have some guidance on this. It almost seems like registering the dlls during the computer startup part doesn't actually register them for the users that login. Can anyone shed some light on this? Sorry if this post is a little confusing... Thanks for any help!
 
Perhaps the program is not completely installed by the time the .dll register.

Try monitoring the process list for msiexec.exe. Once this process is no longer running, register the .dlls

Code:
strComputer = "."

set objShell = CreateObject("WScript.Shell")
set objWMI = GetObject("winmgmts:{impersonationLevel=impersonate}!\\" & strComputer & "\root\cimv2") 

do
   boolProcessExists = false   
   set colProcesses = objWMI.ExecQuery("Select * from Win32_Process")
   for each objProcess in colProcesses
      if (objProcess.Name = "msiexec.exe") then boolProcessExists = true
   next
   wscript.sleep 1000
loop while (boolProcessExists)

wscript.sleep 500

objShell.Run "regsvr32.exe c:\windows\system32\file.dll"
-Geates
 
Is the script actually waiting for the MSI installation to finish before attempting to register the .DLLs? I have seen some installation programs that kick off secondary processes, so you may also need to put in a loop to monitor the process list until msiexec or any other installation program has been stopped for 15-20 seconds.


PSC

Governments and corporations need people like you and me. We are samurai. The keyboard cowboys. And all those other people out there who have no idea what's going on are the cattle. Mooo! --Mr. The Plague, from the movie "Hackers
 
I think for most purposes, simply monitoring the msiexec.exe is safe. But you raise an interesting point! I suppose one could compare a list of processes before the MSI was run with a constantly monitored list until is equal the original. Just a thought.

-Geates
 
bad form on the part of the vendor, drives me mad when they do that, SCCM client is a prime example
 
Thanks for everyone's help. I added some code in to check and see if those dll's existsed before trying to register them. In my two tests so far, things seem to be good. I will let you know if I experience anything else. Thanks!
 
Okay, I was wrong....

Sorry to bring this back up, but I wanted to provide an update.

This is still not working correctly. For whatever reason, the script is not registering the dll files. What I had to do was create a separate batch file and then use the script to call that batch file. The script is calling that batch file at the same exact place as it was trying to register the dll files. The same exact commands are being used in the batch file as the script was using. But calling the external batch files seems to be working 100% of the time.

But even with that, I am still having an issue. The script runs and seems to install fine, HOWEVER, if a user already has a user profile on that machine, the program doesn't work. If a new user logs on, and the machine builds a new profile, then the program works fine. I can rename the existing user profile and force the machine to create a new one and then it works fine. Does anyone have any idea of what in the profile needs to be "reset" or changed in order to get the user to see the program? Preferably something that won't mess up the users desktop and mail settings?

If anyone is interested in the script, I can post it when I get back to work tomorrow... thanks.
 
You may need to export the reg keys from a new user profile hive and import them into the existing profiles hive.

I'll take a look at it. I wrote a collection of scripts to ease new/upgraded pc deployment. Maintaining the users profile from HDD to HDD was a big concern and I feel I've got a pretty good grip on user Profiles.

-Geates
 
hmm, sounds silly but try putting

"cmd /c regsvr32.exe" instead of just "regsvr32.exe
 
Silly, it is not. Specifying the comspec is the only way I've been able to register DLL.

-Geates
 
I lied. I found an old script that doesn't specify the comspec. This is how I did it.

objShell.Run "c:\windows\system32\regsvr32.exe /s " & strInstallFolder & "something.dll"

-Geates
 
yeah, i did start typing the suggest to fully qualify the path but perhaps with the use of %windir% etc, even a check to see if the file is there might not be going to far, not to mention for debugging purposes (which seem appro here) capturing the return code from the .Run method to see what is happening...
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top