How do I register files through KACE
I work for a large software vendor. Our product is being used by one of our customers who utilizes KACE to deploy software to their machines. These machines are locked down pretty tightly, and users have no ability to install by themselves. Our software package is an installshield bootstrapper that contains the Citrix Receiver, followed by our own program. As part of the install of our program, there is a DLL and EXE file that need to be registered. When our customer simply pushes our installer through KACE, the install goes through, but these particular files do not register, or rather, do not register correctly. Originally, our program was never written or intended to be written, to be run under the System context, which they say is how KACE installs the applications so they do not need to elevate their users. As part of our troubleshooting, we had them push the install with KACE, then using a .BAT file, manually unregister then register the two needed files. Prior to having them do this, I tested running the registrations using PSEXEC from Sysinternals to make sure that running under the system context was not the root of the problem. Also, the DLL and EXE that need to be registered are within our own directories, not in any system directory or anywhere within the Path.
The .BAT file contains the following lines to register the files:
REGSVR32 -U C:\GFX\BIN\DESKAG04.DLL
C:\GFX\BIN\DESKAG04.EXE /UNREGISTER
REGSVR32 C:\GFX\BIN\DESKAG04.DLL
C:\GFX\BIN\DESKAG04.EXE /REGSERVER
Is there anything special about KACE that would cause these registrations from working in this method? Looking through some of the other posts here, I have seen reference to something about setting dependencies. Is that something that may be needed in this case, since the files we are trying to register are not in the active directory? As I said, using PSEXEC running in System context, the above commands are successful and our application works correctly. Not having direct access to KACE or any experience using it, I am having trouble narrowing down the problem, or even coming up with the correct questions to ask our customer to look for in KACE.
0 Comments
[ + ] Show comments
Answers (6)
Please log in to answer
Posted by:
anonymous_9363
6 years ago
The obvious route here would be to perform 2 installations, *both* with verbose logging: one using PSExec and the other using KACE. Any difference will be highlighted by comparing the 2 logs.
Next, for the record, I was suggesting that the installation package be rewritten, not the application itself.
Lastly, with regard to having no visibility to the installer's inner working, that's a shocking revelation from an advanced support rep. Download and install InstEdit - it's Orca on steroids - and use that to browse through your company's MSIs.
Comments:
-
I generally use ORCA, but I will give InstEdit a try also. When I said no visibility, what I meant was, I do not get to look at the installshield packager to see what the programmer is doing. I can look at the installer itself as you mentioned, although it usually isn't necessary. As you can tell from the MSI you looked at, very little has changed in quite some time, and I generally already know how to fix 99% of issues that may show up with it.
I knew what you meant when you said rewrite, meaning the install package. if you have been in a corporate environment, I am sure you know that a deprecated product generally doesn't get development hours assigned to it, which is why I am having to stumble through making something work that was not intended to work in this way. Much easier to assign Support and QA hours to resolve an issue. To be fair, I do have several programmers that are assisting, but I have to have the right questions to ask them, and anything that involves risk to customers at large, will be refused, even if it is the best long-term solution. - adarict 6 years ago-
"will be refused, even if it is the best long-term solution"
Not good my friend, but I bet is not something you can control.
Anyway, Why just not creating a script with three steps.
Steps 1 and 2 register or unregister stuff, and then step 3 to execute the installer?
See:
http://www.itninja.com/question/need-to-mass-register-a-dll-file-using-kace - Channeler 6 years ago-
And if it is a 32 bit application and/or dll, you may want to launch regsvr32 from c:\sysnative, I've run into that in the past. - five. 6 years ago
-
You are correct in that I have no control over it. The registration must happen after the install, as the files do not exist until the install finishes. yes we could hand them the files and do it that way, but then the install would just try to register over the top and we would likely be back in the same situation. I had read the thread you posted prior to my posting here. Because I don't have access to KACE itself and have never used it, I am not sure about the scripting option being discussed. We do not have a problem getting the files there, or for that matter, calling REGSVR32 through a BAT file. What I was wondering about that though was, should we be using some directory OTHER than just calling REGSVR32.EXE and putting the path to our DLL? - adarict 6 years ago
-
@adarict I haven't registered DLL via BATs, I always use the method described in that other post, it works fine.
Your customer may need to contact KACE Professional Services, as this not the usual break\fix thing, this will require an analysis of your software, the customer's environment and to develop a tailored script to achieve what we want.
If they would like to talk to Kace Professional Service team, please have them email them at remoteconfig@quest.com .
Before any work is done, they will speak to you and build a statement of work; as well as provide you with a quote. - Channeler 6 years ago
Posted by:
anonymous_9363
6 years ago
OK, good.
So, the next step is to have your customer do the 2 installations and log comparison. That's the only way forward, since in essence KACE is doing exactly the same as PSExec, in terms of using the System account. It would also help if we could get a look at the command line being used, as well as any transform.
Posted by:
anonymous_9363
6 years ago
If your installer is MSI-based, the registration should be in the package (and by using the correct tables, not running Custom Actions), not handled externally. I would expect "a large software vendor" to know this.
If it's not MSI-based, why not?
Comments:
-
We use Installshield for the bootstrapper to package the Citrix Receiver, and then call our own package which IS an MSI. For nearly 10,000 firms that use our software, everything registers correctly. This is the only firm using KACE that has a failure with the registering of these two particular files. They only ly fail to register when it is deployed with KACE. This package is a stable and mature package that has been continually updated since 2001, and we have never had a customer have an issue with the registration of these files. Granted, not many of our customers use KACE. Most use System Center or XenDesktop. - adarict 6 years ago
Posted by:
anonymous_9363
6 years ago
All information which would've been handy to have had at the outset but hey, ho...
Originally, our program was never written or intended to be written, to be run under the System context, which they say is how KACE installs the applicationsand
Most use System Center or XenDesktop.
...both of which default to using the System account.
I fail to see how you can have been authoring MSIs for that length of time and not made it robust enough to handle user-based and machine-based installations. This stuff is meat-and-potatoes to any half-decent packager.
Anyway...If the MSI is built correctly, how do you know that the registration has failed? Do the components get installed correctly? What does the client's log tell you? They've logged it verbosely, right?
>half-decent packager
Reading between the lines of your response, your package is using CAs to register these files. Is that right?
Reading between the lines of your response, your package is using CAs to register these files. Is that right?
Posted by:
anonymous_9363
6 years ago
Is this your company?
EDIT:
Yes, it is. I've opened 'Global fx Components Update.msi' and...well..it's not pretty, is it? Has anyone ever run validation against it? Just marvel at the CLSID and ProgID warnings!
EDIT:
Yes, it is. I've opened 'Global fx Components Update.msi' and...well..it's not pretty, is it? Has anyone ever run validation against it? Just marvel at the CLSID and ProgID warnings!
Since you have InstallShield, I would recommend rebuilding this package from the ground up. At least then it would comply with standards, with the proper tables used throughout. Then you'd have a robust installer with no need for post-installation fudging.
Comments:
-
Thank you for the response. To clarify, I am a network admin, QA Engineer, and advanced support rep. I am not a programmer and know only the basics of how the package was built. I can't get into my own opinions, particularly since you have identified the company. I enjoy keeping my job. As far as how we know the files are not registered correctly, our logging within the application itself shows the calls failing. A side effect of this is an error that comes up on the end-user's machine. Re-registering the files resolves the issue.
There is no doubt that the best way would be to rewrite the application from the ground up. This is a legacy application and is being deprecated, meaning there are no hours available for a complete rewrite. As I said, this is the only customer experiencing the issue, and the only thing out of the ordinary in comparison with most of our other customers, is that they deploy through KACE. When this customer installs manually, or through PSEXEC, They do not have an issue. I am in the unenviable position of seeking answers from outside, without having full visibility to either the inner workings of our installer, or the customer's environment. The customer also does not seem to have significant experience with KACE, What I mean by that is, they have it set up and it manages somewhere around 600 workstations, but they appear to be using only basic functionality of it.
My initial question was just to see if there was something simple with KACE that an experienced KACE administrator would know right off the bat. - adarict 6 years ago
Posted by:
anonymous_9363
6 years ago
the files do not exist until the install finishes
Ummm...if they don't exist, God must be removing them because, taking just the DLL component as an example:
Component table:
Component ComponentID Directory_ Attributes Condition KeyPath
deskag04.dll {52B5CB30-1B88-40EB-8CAA-5366919F88AA} INSTALLDIR 0 <null> deskag04.dll
FeatureComponent table:
Feature_ Component_
Desktop_Integration deskag04.dll
Feature table:
Feature Feature_Parent Title Description Display Level Directory_ Attributes
Desktop_Integration <null> Desktop Integration <null> 22 1 INSTALLDIR 0
Property table:
Property Value
INSTALLLEVEL 100
So, INSTALLLEVEL = 100, the feature installing the component has a Level value of 1 (as do they all), therefore that component will get installed.
My guess is that there is either a CLSID missing from the package or its GUID/class name/path is wrong. As I mentioned, the only way forward is to do a log file comparison.
the install would just try to register over the topSo what? The 2 steps do the same thing.
My guess is that there is either a CLSID missing from the package or its GUID/class name/path is wrong. As I mentioned, the only way forward is to do a log file comparison.
