Wise & Software Mangler Distribution
April 21, 2008
Software Manager
The distribute function ties in heavily with the use of conflict management. This is a very complex phase to understand and has some definite advantages and disadvantages. The advantages are only recognised if and when you are running a full conflict management solution. The main reason for the distribution phase is to allow Conflict Manager to copy files to and from other packages already in the repository.
The output of this step is that all files from the MSI / MST combinations are copied from the current package to the Wise Sharepoint under the following location.
[WiseSharePoint]000 ‘ From now I will refer to this as [000]
In order to demonstrate some important processes lets assume we start with the following items in our sample package
Application Name = APPLICATIONA
File Name = FILE1.DLL (Version 1.0)
WiseSourcePath = .\Program files\TestApplication\FILE1.DLL
Working Folder = [WiseSharePoint]Projects\APPLICATIONA
When package distribution is run files within the package are enumerated each file is then compared against the (wamdb.idx). If the file does not previously exist it will be copied into [000]001\FILE1.DLL. At this point our applications sample information will now look like this.
Application Name = APPLICATIONA
File Name = FILE1.DLL (Version 1.0)
WiseSourcePath = ..\..0001\FILE1.DLL
Working Folder = [WiseSharePoint]Projects\APPLICATIONA
Note: The change in the WiseSourcePath table.
The change in the WiseSourcePath table has a potential negative impact but it is done for a very specific reason. In my opinion the WiseSourcePath table should not be modified and instead Wise should of created a new table such as WiseSoftwareSourcePath or something similar. (however that is not the case so we have to cater for the negative impact of this step.)
If we then run the same distribution on another similar package “APPLICATIONB” and assume this application also contains the same FILE1.DLL (version 1.0) the distribution function will check the Repository Database and find that the file already exists.
Application Name = APPLICATIONB
File Name = FILE1.DLL (Version 1.0) and FILE1.DLL (Version 2.0)
Working Folder = [WiseSharePoint]Projects\APPLICATIONB
WiseSourcePath = .\Program files\TestApplication\FILE1.DLL and .\Program Files\TestApplication\Test\FILE1.DLL
If the file does exist the files version would be checked, where the files version was the same no files would be copied to the repository, however the WiseSourcePath entry for “APPLICATIONB” would be updated to show the same after distribution path as APPLICATIONA in the above example.
Application Name = APPLICATIONB
File Name = FILE1.DLL (Version 1.0)
Working Folder = [WiseSharePoint]Projects\APPLICATIONB
WiseSourcePath = ..\..0001\FILE1.DLL
If the file does exist and the file version is different from files already stored in the repository. Then a new folder will be created and its number incremented from the folder that last contained a copy of the file with the same name.
Application Name = APPLICATIONB
File Name = FILE1.DLL (Version 1.0)
Working Folder = [WiseSharePoint]Projects\APPLICATIONB
WiseSourcePath = ..\..0002\FILE1.DLL
Note: The WiseSourcePath has now incremented from ..\..0001\FILE1.DLL to ..\..0002\FILE1.DLL.
The intention here was to ensure that all APPLICATION FILES for each application in the Software Manager will be available and relative to all packages currently imported in the software Manager from the WiseSharePoint. However each file will only ever be referenced once regardless of how many applications contain the file name. However if more than one version of the same filename exists you will find multiple folders housing each of the individual copies of the respective files. Therefore the folders with the lower numbers are more likely to contain more files from the various applications which have already been through the Wise Distribution phase.
At this point I expect most of you are reading this quite confused or even wondering why would Wise bother with such a step. The answer to that question is as complex as the question itself. If you consider what conflict manager is trying to do, it is basically trying to ensure all applications are sociable with all other applications already imported into the Software Manager. In order to do this there is likely going to be a time where you would like to switch files from one package to another. To cut a very long and complex story short this is why the distribution phase is run. It basically allows functionality within Conflict Manager to be enabled, this functionality allows the user to copy files from one package to another package.
Prior to distribution the WiseSourcePath table has entries which are relative to the current working file. For example APPLICATIONA.WSI. All files relating to APPLICATIONA are present in the folder for APPLICATIONA. (no rocket science here) However after distribution each file entry in the WiseSourcePath table will look similar to this.
..\..0001\FILE1.DLL.
Note: ..\ means that the package will step up a folder from its current location.
So if we are working on APPLICATIONA which is in the WORKING FOLDER APPLICATIONA in this example. If we step up 2 directories (I.e. ..\..\) we will be at [SharePoint] from there the remaining path of 00001 is easily found from the SharePoint location.
If we are working on APPLICATIONB which is in the WORKING FOLDER APPLICATIONB in the same example. If we step up 2 directories (i.e. ..\..\) we will also be at [SharePoint] from there the remaining path of 00001 is easily found from the SharePoint location.
Basically what I am trying to say is, if we are working in a package directly under the projects folder no matter what the package location is 2 folders up is [SharePoint] in effect this means that each package that has had distribution run on is is now relative to all other packages within Software Manager. This is a very important part of understanding conflict management in its entirety.
Conflict Management
Using the same example applications mentioned above, if we now look at this from the perspective of the Wise conflict management tool we will see a different picture of why this is done.
For example:
If we assume now we have imported both applications into conflict manager. Remember that both packages had FILE1.DLL present as such we would see that each of these applications would conflict against each other as they both had the same file name existing in various locations.
The following picture is taken from an actual conflicting application. The top window is the currently selected package. The bottom window is all other packages in the Software Manager that conflict withe package in the top Window.
The circled item is the files in the currently selected application which is conflicting with other applications.
The items circled below are the other applications in conflict manager which are actually conflicting with the item which is selected in the screen at the top section.
The two buttons in the middle are used to swap files between other packages.
Note: This item is only available if the distribution option is used, the view depicted here is from a package which has not run the distribution phase
Selecting a package from the view on the bottom will allow the grayed out middle items to be selected. Then selecting either button will allow you to move dll’s from one package to another package. Note this heavily integrates with the items listed in the WiseSourcePath tables earlier in this post.
Pushing this "Copy Up" or "Copy Down" presents the above item. The two checkboxes perform the following.
- Copies the complete file from other package to the current package
- Copies the files component GUID only from other package to the current
So for the purpose of explaining Conflict Management processes lets assume that the TOP window is APPLICATIONA and the BOTTOM window is APPLICATIONB. If we select the "Copy UP" option we are effectively saying lets copy the file from the application selected in the BOTTOM window, in this case APPLICATIONB into the application selected in the TOP window. In this case APPLICATIONA.
Prior to distribution you will recall we have this information.
Application Name = APPLICATIONA
File Name = FILE1.DLL (Version 1.0)
WiseSourcePath = .\Program files\TestApplication\FILE1.DLL
Working Folder = [WiseSharePoint]Projects\APPLICATIONA
and
Application Name = APPLICATIONB
File Name = FILE1.DLL (Version 1.0) and FILE1.DLL (Version 2.0)
Working Folder = [WiseSharePoint]Projects\APPLICATIONB
WiseSourcePath = .\Program files\TestApplication\FILE1.DLL and .\Program Files\TestApplication\Test\FILE1.DLL
After distribution we had this information.
Application Name = APPLICATIONA
File Name = FILE1.DLL (Version 1.0)
WiseSourcePath = ..\..0001\FILE1.DLL
Working Folder = [WiseSharePoint]Projects\APPLICATIONA
and
Application Name = APPLICATIONB
File Name = FILE1.DLL (Version 1.0)
Working Folder = [WiseSharePoint]Projects\APPLICATIONB
WiseSourcePath = ..\..0001\FILE1.DLL
Based on this if we are Managing Conflict management for APPLICATIONA you will note our Working Directory is
[WiseSharePoint]Projects\APPLICATIONA
We are however interested in copying file from APPLICATIONB into APPLICATIONA. So in order to achieve the copy APPLICATIONA reads the WiseSourcePath table of APPLICATIONB. Prior to distribution the WiseSourcePath table for APPLICATIONB reads as:
WiseSourcePath = .\Program files\TestApplication\FILE1.DLL and .\Program Files\TestApplication\Test\FILE1.DLL
The current working directory is [WiseSharePoint]Projects\APPLICATIONA as such Wise will look into
[WiseSharePoint]Projects\APPLICATIONA\Program Files\APPLICATIONB which does not exist in APPLICATIONA’s working folder.
After the distribution phase the WiseSourcePath table reads as WiseSourcePath = ..\..0001\FILE1.DLL.
So with a working directory of [WiseSharePoint]Projects\APPLICATIONA\..\..0001\FILE1.DLL we will find the path to the source files for APPLICATIONB. Regardless of the application selected if the distribution phase is run all applications can find files from all other applications.
Well that about wraps the distribution phase up, its very complex to put into words I would be interested in any feedback about this document. Its hard to understand implement and even harder to write about it.
This is some pretty smart work on behalf of Wise. I hope this can help somebody struggling with the principals of Software Manager.
Enterprise Deployment Architecture 
April 30, 2008 at 5:57 pm
Hi John,how do you treat vendor msi\’s? For example, a vendor msi has multiple PE files in one component. One of these PE files is in a separate component of a Captured package. Do you move the vendor PE file into it\’s own component, so that it corresponds to your captured application? Major incursion into the vendor setup logic…This would really interest me, as I think the idea of the automated conflict resolution of Wise is great, however due to the fact that more and more vendors are moving to the MSI format, (and by the way producing totally cr*p msi\’s in the process, multiple pe files per component, no regard whatsoever for ICE checking etc.) that the conflict manager as a tool is loosing it\’s usefulness as a tool to resolve conflicts, but is still very useful in identifying conflicts.What are your thoughts on this?ThanksPhil
May 4, 2008 at 11:27 am
Hi Phil,
An interesting topic and one that raises considerable room for debate. If one was to go down the automated path of conflict management little care would be taken for or against the vendor msi. I have seen alot of sites that don\’t touch CMDB, don\’t use CMDB on vendor msi\’s etc.
I have also tried using CMDB on vendor msi\’s and more often than not it results in failure of the vendor MSI as a result. I think on the whole the concepts of CMDB are solid. However in practice its often poorly implemented and doesn\’t cater too well to the vendor scenario.
Now with all that being said it is possible to create a separate ruleset within wise which is less agressive and doesn\’t split components as you have discussed here. This for me has resulted in less trouble after a vendor MSI has been through the CMDB process.
So based on that I think the best way to achieve a decent CMDB approach is to define your rules upfront and ensure you follow them religiously. In a larger team make sure you have the most senior member in the team monitoring others CMDB work as you are likely aware it doesn\’t take long before you have a big fat mess on your hands if its not monitored properly.
I have always utilised CMDB whereever I could however I do feel that virtual packaging is likely to replace its use in the years to come. I also believe that the lack of understanding of CMDB processes is high and the result is many people are not aware that rules such as splitting components as you mentioned not only improve uninstall but in certain instance actually allow the app to be installed correctly. This and future blogs posts on the topic will be trying to provide awareness of those issues.
May 16, 2008 at 10:31 am
Excellent blog (once you get your head around it) in terms of helping fully understand (to a certain extent, i\’m sure there\’re still more things to this) how conflict manager and software mangler works.
Can you write up a post on how you would initially setup/configure SMDB and CMDB? Thanks Yoda X-D
May 16, 2008 at 11:30 am
Also, in addition to the previous comment, can you please put up a blog on what happens when you import a transform into SM.