Novadigm radia software

Radia should be running under the system account that is domain admin. These are only populated if a user is logged on. Is it possible that a connect was run while an administrator was logged on? I suspect that your issues are more related to how the last connect was run rather than changes in your domain. Check the other ones down the lib directory too.

I also suspect that you have multiple directories under the lib directory which causes multiple catalogs to be obtained. Care must be taken with uid and startdir parameters. Resources Support. CyberRes Academy. Partner Portal. Please contact Do you want to work offline?

There is no firewall. Please help Reply Cancel Cancel. If you are able to ping the server from the XP box then the most likely problem is that the RCS service is not started on the server.

Still another problem can be that port is blocked somewhere along the way through router configuration. Those are some of the major causes of return codes. Verified Answer. Did you edit the install. I'm pretty familiar with all the components of the product except the OS manager and patch manager.

OS manager - i'm going to start working with soon and we just got rid of patch manager. Posted by: turbokitty 13 years ago. I'm pretty shocked.. I mean, a really horrible product. It's overly complicated, poorly supported and documented, and ridiculously expensive. It's really too bad you got dragged into it. Are you buying the "advanced publisher and client extensions"? If you don't, it distributes software in a really ham-fisted way.

One that installs per-machine, and another that installs for each user. It's really stupid REFWI is not intuitive or all that powerful. I much prefer AdminStudio.. Posted by: Inabus 13 years ago. The HP Support is absolutely horrible I'm actually surprised to hear people don't like it. Like i said I don't use it all that often, but it has really helped me out in alot of situations If for nothing else, to capture small setting changes.

I have a vbscript that I use to inject the current user settings to all users on that system at installation time Lets the MSI run as the user logged in, of course we don't have a locked down environment.

OK, I see. Yes, if you have a locked-down environment, you can't populate HKCU keys without splitting them into a separate service and running it in the user's context. This means you have to split vendor MSI's into two, breaking vendor support. It's a nightmare, and it has nothing to do with "properly coding the MSI".

Gmorgan's script may be a solution for you, but are you locked down?? Yes, we do have a locked down environment. So, using active setup to heal CU settings on user logon would not work? I thought past this point it becomes a Windows Installer issue and not a Radia issue? I am drawing on past experience with the way Tivoli deploys and runs an install in this case.

Are the installing credentials not similar? I wouldnt use active setup to do anything as it delays the login for the user, use normal self repair on key paths in the current user key. This way the app will self repair when the user wants to run the application, thus saving time during the login process.

Inabus, I brought up the AS just as an example. Please refer to my earlier comments of "a properly coded MSI" where of course traditional entry points would suffice. The issue of self healing in this case is a discussion on building and deploying MSIs via Radia and any deviation from the normal expected behavior; consequently what I would need to do as a packager to emulate said expected norm. And in any case, it is all a matter of what you are trying to achieve and the best possible way to do so.

Remember that using traditional entry points, the user will still experience a delay on program launch, albeit not in the login process, but a delay all the same.

So whether the traffic is heavy getting out of your sub-division on your way to work, or getting off the highway; the net result is the same wait It could be that the user would never launch 9 of those packages as his job doesn't require it, so infact you have delayed him un-neccassarily. Anyway, doesn't really matter as thats a theoretical discussion about what "could" happen.

Regardless of that just author your MSI's as normal, ignore Radia, and only worry about that when your MSI is authored and tested outside of the deployment tool.