I would suggest using [PersonalFolder]word1.doc to set the element content. PersonalFolder is a Windows Installer system folder property that will resolve to the My Documents folder of the current user. System Folder Properties http://msdn.microsoft.com/en-us/library/aa370905(v=VS.85).aspx#system_folder_properties You can take a look at LogonUser and USERNAME properties if you are just interested in the user name: User Information Properties http://msdn.microsoft.com/en-us/library/aa370905(v=VS.85).aspx#user_information_properties Please check the XML File Changes help to see how to set up this view to update the xml file and element that you are looking to do. -Ajay ... View more

Hi Bruno, App-V packages are not truly OS independent. This is because the App-V client does not simulate an entire OS - App-V can't be used for OS application compatibility. The client sometimes gives a virtual application a virtual resource, and sometimes gives it the actual physical OS resource. If an application installed physically on a Win 7 machine will not work, then most likely, an App-V package for this app will also not work on Win 7. To debug the issue you are seeing, I suggest trying a couple different approaches: 1. Try copying the DLLs that can't be located in your 32-bit system folder in the physical machine to see if this resolves the problem (just to get a feel for the scope of the problem). 2. Try including the File system diagnostic tool and rebuilding the App-V package. Then you can use the AppVLauncher to launch the Virtual File System tool and get a feel for the file structure seen by the virtual package. You could go to the 32-bit system folder and verify that the MFC DLL is present (if it is supposed to be there). 3. You can try running a recent copy of Process Monitor tool available from Microsoft. Run this tool on the physical machine with the command line switch /externalcapture. Then it will also report registry accesses within the virtual bubble. Look for mfc42.dll in the report and check to see where it was searched for and determine why it was not there. -Ajay ... View more

In general I would recommend against using the professional logging option because our setup technology agnostic Installation Monitoring and Snapshot technologies should be perfectly capable of capturing the system changes made by the setup. I believe we are considering either deprecating this option or else at least not selecting it by default in the Repackaging wizard. Regards, Ajay ... View more

Hi DBrewer, Although the Repackaging Wizard suggests to use the Professional Logging method, I recommend that you do not use this method during the repackaging. Our standard Snapshot mode or Install Monitoring mode should be fully capable of capturing the system changes made by the InstallScript setup that you are Repackaging. Please try not using the Professional logging option and let me know how it goes. Regards, -Ajay ... View more

Hi Jakob, Unfortunately, in recent releases of AdminStudio, running Repackager remotely with an evaluation version is not supported. So you will not be able to evaluate the remote Repackager functionality. Instead please consider installing the full AS eval on the machine where you want to repackage to evaluate the Repackager. I know that this approach is against best practices because installing AS dirties the machine, but you should be able to evaluate the Repackager functionality this way. You can deselect most of the other features besides Repackager to install a smaller footprint (I think you can deselect all but Distribution Wizard and Repackager). Hope this helps! -Ajay ... View more

I agree with Robert that your approach to addressing the ICE03 validation error is valid. Leaving this issue in the MSI package shouldn't cause any issues on systems supporting long file names - which is just about every system out there these days. We have an issue reported for this with issue number 1-AWE2X. Regards, Ajay ... View more

The best single reference for Windows Installer conditional statements can be found in the following link: Conditional Statement Syntax http://msdn.microsoft.com/en-us/library/aa368012(VS.85).aspx ... View more

Hi, I see that you are not able to use the workaround I presented because you have the LANDesk limited edition which does not come with InstallShield Editor. I think you may be able to workaround this issue by directly editing the INC file. This is a text file that you can open with Notepad. At the bottom of the file you will find the Links (shortcuts) section that lists all of the shortcuts along with their icon information. Here is an example line: CreateLink('BusinessObjects','%ProgramFilesFolder%\Business Objects\BusinessObjects 5.0\BUSOBJ.EXE','','%WindowsFolder%\Installer\{2B989026-FE29-4EE6-AC98-46816D43A32F}\IconFF937CC6.exe,2','%WindowsVolume%Documents and Settings\All Users\Start Menu\Programs\BusinessObjects 5.1.6','BusinessObjects','') You can see that IconFF937CC6.exe is the icon file with an index of 2. So this could be altered here before building the Repackager project. I would verify whether the icon EXE (Icon_CoWriter.exe) that is presenting the error for you is really an EXE file. If it is really an ICO file, then you may want to make a copy of the EXE file with the extension ICO in the same folder as the EXE. Then modify the CreateLink command to use the ICO file instead and rebuild. You can also just pick one of the actual executables in your project as the source of the icon. Hopefully, you will be able to workaround this problem. -Ajay ... View more

The 1920 error unfortunately does not narrow down the cause of the failure with starting the service. Here are some things you can look into to try to get to the bottom of this: 1. Check the ServiceInstall and ServiceControl tables in the built MSI. Compare with the documentation for these tables and also check to see if these tables were being used in the original install (before repackaging) to see how they were populated before. 2. Verify that all dependencies for the service EXE (CentralDICOMServer.exe) are present. 3. Verify that the correct internal name of the service (not necessarily the display name) is being used as the key of the Service* tables above. 4. Try to remove the ServiceControl table entries, then install the MSI, and then manually try to get the service to start-up successfully. Once you determine what the problem was, then you can correct it in the MSI (you could use ProcessMonitor, do a file diff with the original install, etc). Hope this helps! -Ajay ... View more

Glad to hear that reconversion worked with the hotfix! It is technically possible to manually edit the captured INC and ISR or NIR files to ensure that backslashes and double quotes appearing within registry value names or Ini key names are escaped with a backslash. But it could be time consuming for large packages that may have multiple entries with this problem. The registry data can be found in any ISR or NIR files, and the Ini data can be found in the INC file. You may find that it is easiest do the reconversion. Or else, you may be able to figure out some way to quickly identify unescaped backslashes or double quotes in the Repackager project files. -Ajay ... View more