Software Deployment

Here is the script... I wrote it a while ago ... never got around to commenting it...

I publish this as a second package with zservice. I make sure my applicaiton Service Group is set to Dependant, and then make a connection to this file after my application service.
here is a quick walk through of the scripts function...
First the script records the keys that are loaded in HKU. Then the script locates all the user profiles in the "documents and settings" folder for each drive and loads any NTuser.dat files into the HKU hive in the registry using the foldername as the Key name. The script then enumerates all the keys in HKU, which is now represents all user hives on the machine, and writes the settings. After the script has completed it unloads the hives that were loaded.

The piece that enumerates the users is this piece:


[blockquote]
For Each sSID In arrOriginalSIDS

fnRegDwordWrite HKEY_USERS, sSID & "\Software\Policies, "TestEntry1",2
fnRegStringWrite HKEY_USERS, sSID & "\Software\Policies", "TestEntry2", "Number 2" 

Next[/blockquote]
You can add as many as you want ... I included to has an example ...
HKEY_USERS is teh HIVE you want to connect to
sSID &  "\Software\Policies" - sSid is the key listed directly under HKEY_USERS ... So HKEY_CURRENT_USER\Software\Policies would be put into this as -  sSID &  "\Software\Policies"
"TestEntry1" is the Value
2 is the Value Data (Notice the DwordWrite writes an integer, not a string)



Disclaimer: use at your own risk...


'==========================================================================
'
' NAME:
'

' COMMENT:  Windows XP only
'==========================================================================

Const HKEY_USERS   = &H80000003
Const HKEY_LOCAL_MACHINE = &H80000002
Const HKEY_CURRENT_USER  = &H80000001

Dim oFSO : Set oFSO = CreateObject("Scripting.FileSystemObject")
Dim oDrives : Set oDrives = oFSO.Drives
Dim oShell : Set oShell = CreateObject("WScript.Shell")
Dim oDict : Set oDict = CreateObject("Scripting.Dictionary")
Dim arrOriginalSIDS, sSID
Dim oReg : Set oReg = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")

oReg.EnumKey HKEY_USERS,"", arrOriginalSIDS
For Each sSID In arrOriginalSIDS
oDict.Add sSID, sSID
Next
Dim sDrive
Dim oFolder, oCurrentFolder
For Each sDrive in oDrives
If sDrive.DriveType = 2 Then
   'Set Static path to Docs and Settings for given drive letter
   Dim sCurrentFolder : sCurrentFolder = sDrive & "\Documents and Settings"
   'Check if Documents and Settings Exists on current drive
   If oFSO.FolderExists(sCurrentFolder) Then
         'Grab Folder Object
         Set oCurrentFolder = oFSO.GetFolder(sCurrentFolder)
         'Collect array of Docs and Settings Subfolders
         For Each oFolder in oCurrentFolder.SubFolders
               'Check for NTUser.dat which contains User Hive Information
               If oFSO.FileExists(oFolder.Path & "\NTUser.dat") Then
                     'Reg.exe (embedded in Windows XP) to load Hives
                      oShell.Run "reg.exe load ""HKU\" & oFolder.Name & """ """ & oFolder.Path & "\NTUser.dat""",0,True
               End If
         Next
  End If
  End If
Next

oReg.EnumKey HKEY_USERS,"", arrOriginalSIDS
For Each sSID In arrOriginalSIDS

fnRegDwordWrite HKEY_USERS, sSID & "\Software\Policies, "TestEntry1",2
fnRegStringWrite HKEY_USERS, sSID & "\Software\Policies", "TestEntry2", "Number 2" 

Next

For Each sSID In arrOriginalSIDS
If NOT(odict.Exists(sSID)) Then oShell.Run "reg.exe unload ""HKU\" & sSID & "",0,TRUE
If NOT(odict.Exists(sSID)) Then oShell.Run "reg.exe unload ""HKU\" & sSID & "" & """" & "",0,TRUE
Next


Function fnRegDwordWrite(ByVal sRegHive, ByVal sKey, ByVal sValueName, ByVal sValue)
Dim oRegistry : Set oRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
oRegistry.CreateKey sRegHive, sKey
oRegistry.SetDwordValue sRegHive, sKey, sValueName, sValue
Set oRegistry = Nothing
End Function
Function fnRegStringWrite(ByVal sRegHive, ByVal sKey, ByVal sValueName, ByVal sValue)
Dim oRegistry : Set oRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
oRegistry.CreateKey sRegHive, sKey
oRegistry.SetStringValue sRegHive, sKey, sValueName, sValue

Set oRegistry = Nothing
End Function
Function fnRegStringRead(ByVal sRegHive, ByVal sKey, ByVal sValueName)

Dim Result, sValue

Dim oRegistry : Set oRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
Result = oRegistry.GetStringValue(sRegHive, sKey, sValueName, sValue)

If Result <> 0 Then sValue = ""

Set oRegistry = Nothing
fnRegStringRead = sValue
End Function
Function fnRegDwordRead(ByVal sRegHive, ByVal sKey, ByVal sValueName)

Dim Result, sValue

Dim oRegistry : Set oRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
Result = cstr(oRegistry.GetDwordValue(sRegHive, sKey, sValueName, sValue))

If Result <> 0 Then sValue = ""

Set oRegistry = Nothing
fnRegDwordRead = sValue
End Function

Function fnExpandedStringWrite(ByVal sRegHive, ByVal sKey, ByVal sValueName, ByVal sValue)
Dim oRegistry : Set oRegistry = GetObject("winmgmts:{impersonationLevel=impersonate}!\\.\root\default:StdRegProv")
oRegistry.CreateKey sRegHive, sKey
oRegistry.SetExpandedStringValue sRegHive, sKey, sValueName, sValue

Set oRegistry = Nothing
End Function

HP Radia ... is now called HP Client Automation. I still like to refer to it as Radia though...

Radia is actually a complete deployment solution and the Packager component is only used to publish files to the database. The publisher component is used to publish MSI's or setup.exe etc. They can't be used independantly and require the database component(known as Configuation Server) to be installed somewhere on your network in order to use them.

Since you stated you were looking for something for your repackaging needs - The component you are looking for is REFWI - Radia Extension for Windows Installer. The tool is very good at using pre and post snapshots to create an MSI. I'm not sure how they license this product.

My bad. I should have been a little clearer. My intention is to get some feedback on the Radia Extension for Windows Installer (REFWI) product itself as I come from a WPS background. Radia infrastructure is already in place and running. Trying to evaluate whether REFWI is a complete packaging tool or should we go ahead & still purchase one of the others. If it does a sufficiently good job, then definitely there would be no need to shell out more $$$ for another product as we already have licenses for it. Cheers!

REFWI has a editing tool very similar to ORCA (which is free from Microsoft) ... I've never used it for anything other than creating a package from scratch, which like i said before works very well - as long as you know what should not be in the package. I typically run it on a straight windows image built right off the disk - install the prerequistes for the application - run REFWI to snapshot - install the product and run the post snapshot... This usually results in a fairly clean collection of changes. With Radia though I haven't seen a big reason to repackage any application - I usually just write a wrapper in .Net to perform the actions needed and return the proper return code to Radia.

Every packager has their favorite editor, I happen to be an installshield guy ... So i would recommend purchasing that - i think it runs around 1600$ for the professional edition and it provides, what i think, is a very simply interface for both modifications and MSI creation. A demo can be downloaded from their site, sorry don't have the link.

If your changes to packages are basic table changes - property, launch condition, upgrade table etc. - I would say use ORCA - it fairly easy to use - creates MST's - allows you to view MSP's(if you ever need to).

What version of the Radia Infrastructure are you guys running? 7.2 is suppose to be released July 31st - We upgraded to 5.11 just before they anounced it...

It's always nice to meet another Radia person, doesn't seem like i meet a whole lot. I just got back from the HP software universe in vegas and seemed like pretty small turn out.

-Grant

IS is ok. I have used it on a couple of assignments, but I favor WPS as this is where I am battle tested and certified. There will be need for some complex modifications and builds as I am working at a financial instituition so we will probably acquire WPS for these.

We are currently still on 4.02 and there is a plan in place to upgrade to 5.11, but I do not know the timeline as of yet as I just got here. Maybe they will skip on to 7, but I doubt it given the nature of such businesses. Truth be told, this is my 1st experience with Radia, having used SMS, Zenworks, Marimba, & Tivoli in the past, & so far, it is proving to be a uniquely complicated product. From what I gather it is more popular in Canada & Europe than in the US. I will probably have more to say once I go to a couple of training classes and get down and dirty with the product.

Cheers!

The 5.11 and 7.2(which is actually 5.2, they are doing the version jump so it matches their other products) use the same database - there is no datbase upgrade needed in order to upgrade the infrastructure components.

Feel free to message me if you have any questions about Radia ... 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.

aha! then we will most likely go to 5/7.2 once the case is made... i will definitely take u up on ur advice offer. thanks for the input... cheers!

I'm pretty shocked.. more Radia people.

I've been working with it for about 5/6 years now for various companies and it's terrible. 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. For example, most MSI's with current_user type components don't install properly... but the advanced publisher will tear an MSI into two. One that installs per-machine, and another that installs for each user. It's really stupid... but you have to use it or most current_user data won't install.

REFWI is not intuitive or all that powerful. I much prefer AdminStudio.. but if you buy REFWI, at least you can prevent HP's terrible support from constantly blaming your packaging tool whenever a package fails to install.

Use Radia here, avoid REFWI like the plague and instead use Installshield. I would NEVER use REFWI on its own but would produce quality MSI's independant of Radia then publish to Radia once I had a fully working MSI

P

The HP Support is absolutely horrible ... glad to see that it's not just me...

Wow... I love REFWI ... 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.

turbokitty, MSI's withcurrent user components not installing correctly - Do you mean the CU compoenent doesn't appear to install not the entire MSI right? I have a vbscript that I use to inject the current user settings to all users on that system at installation time... If there are too many to deal with i'll set a key in active setup and set the ZSYSACCT attribute in the ZSERVICE to N... Lets the MSI run as the user logged in, of course we don't have a locked down environment.

What architecture/client are you guys using?
The 5.11 Packager, which is only the installation monitor, is alot faster than REFWI - but they took out the ability to limit your registry scan to a specific location. ... does HP consider it an exhancement request when all i want is an old feature back?... :)

Does this mean that even if I develop the MSI in IS or WPS, once I publish to Radia and deploy, I will be running into CU issues or is this the case only if I use REFWI?

(Looks like we do have the Radia Advanced Publisher for Windows Components)

Radia runs in the System Context, therefore it treats the SYSTEM account as the current user - whether you use IS, WPS or REWFI you will still have current user trouble

OK, I see. I would not consider that trouble as a properly built MSI would take care of populating CU settings. My big issue is on how to create relatively complex but robust MSIs as I was accustomed to doing with either WPS or IS that would contain conditional installs on components and features, install services and drivers, ODBC, myriad CAs, etc...

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?

Cheers!

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.

P

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... [;)]

That isn't actually 100% true, if I have 10 packages on a box, and they all "active setup" repair the packages when I login that could be a large delay. 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.

Machine/User splits are horrible, custom actions stay in the machine section of the split anyway, only shortcuts, HKCR, Private Exe executions and Private Dll executions get switched over, naff tbh. 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.

As to your comment, you asked a question, "So, using active setup to heal CU settings on user logon would not work?" and I responded to that question :)

P

[:D]

have no fear, we are on the same page. just "theorizing..."

ORIGINAL: Inabus

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.

P



This raises an interesting question. In general, are users more tolerant of delays on login or delays on first application launch ? - I guess it must vary a lot from organisation to organisation.

If the Windows Installer package is carefully designed using parent/child features then it is possible (by moving resources to be self-repaired by Active Setup to outer level features) to keep delays to a minimum by reducing the number of keypaths to be checked.

Regards,

Spartacus

Spartacus,
That is an interesting question but my answer would be, it depends on your environment. If your a small company with no roaming apps and the users never move machines then having active setup launches is fine. If your in a corporate environment with 30+ apps on each machine each user using only 3 or 4 of those apps then having all 30+ repair via active setup is an unacceptable delay.

P

ORIGINAL: gmorgan618
Here is the script... I wrote it a while ago ... never got around to commenting it...Grant, could you try and remember to use the 'Code' button? It's marked '<%' on the 'Reply to Message' window.

"properly coded" MSI.. yes.. that's great if you are coding the MSI. What happens when you get a vendor MSI with current user bits? I've been using Radia for years and I've found about ~70% of vendor MSI's with current user bits fail without splitting them in two using the advanced publisher. The same MSI's pushed with SMS or Altiris work just fine.

i've heard some nasty stories about radia over the years too. never had first hand experience tho.

Inabus re this comment


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.
quote:

there is a registry key which toggles machine usability during login. For example you can allow active setup or login scripts to run synchronously or asynchronously meaning that you can allow the user access to the machine whilst this stuff is happening (or the more common option) prevent user from accessing machine whilst scripts are running.

off the top of my head it eludes me but a search on asynchronous and login script coupled with GPO's should suffice

Turbokitty, the project i am on uses Radia to publish every single application, i believe we are currently at 270 odd applications, now a percentage of those havn't been advanced published but I belive that the reason for that is lack of understanding and skill in authoring an MSI to work correctly.

You will always, however, get ones which are basic published as they simply dont work, but those are in the minority.

Jmcfadyen, i guess it comes down to what you want to give your users, i avoid active setup like the plague, just a personal preference i guess.

P

Ian - i'll be honest with ya - i never knew that was there... thanks for the heads up ... I edited that message and mark the code...

John - Radia, now Client Automation ... is actually a pretty great product ... the only real problems I have with it is the crappy support that HP provides and the worthless software forum they offer every year for 2600$ in Vegas in which you are presented with information that has nothing to do with the product...

aha! so vegas was a bust! sorry 2 hear that.

radia (configuration manager/client automation) is really not that bad so far. still trying to get a grip of some of the inner workings, but i now see that it is very akin to marimba in its behavior & that is a beast i came to understand & love. (however crazy that sounds).