It is not necessary for you to dirty your Remote Repackager machine with the Microsoft Visual C++ redistributables.
Instead you can copy the C++ 2010 SP1 redistributable files to your Repackager folder (on your AdminStudio Client Tools machine, not your clean Remote Repackager capture machine)
If you need the VC++ 2010 SP1 files, download the Microsoft Visual C++ 2010 SP1 x86 redistributable from:
http://www.microsoft.com/en-us/download/details.aspx?id=5555
-Install it on one of your machines...but not on your Remote Repackager capture machine, as that would dirty it up. (or just take a VM snapshot prior to installing it and revert it later)
Although probably only a few of the following files are needed by Repackager, I would recommend copying all of the Visual C++ 2010 SP1 redistributable files to your Repackager folder:
atl100.dll
mfc100.dll
mfc100chs.dll
mfc100cht.dll
mfc100deu.dll
mfc100enu.dll
mfc100esn.dll
mfc100fra.dll
mfc100ita.dll
mfc100jpn.dll
mfc100kor.dll
mfc100rus.dll
mfc100u.dll
mfcm100.dll
mfcm100u.dll
msvcp100.dll
msvcr100.dll
vcomp100.dll
-If the OS is 64-bit, go to C:\Windows\SysWOW64\ and copy those files to your AdminStudio Client Tools Repackager folder.
By default, the Repackager folder on 64-bit machines is located at:
C:\Program Files (x86)\AdminStudio\2013\Repackager\
-If the OS is 32-bit, go to C:\Windows\System32\ and copy the C++ files to your AdminStudio Client Tools Repackager folder.
By default, the Repackager folder on 32-bit machines is located at:
C:\Program Files\AdminStudio\2013\Repackager\
On your Remote Repackager capture machine, all you need to do is create a shortcut that points to Repack.exe on your AdminStudio Client Tools machine. For example: On my VMware virtual machine I create a shortcut that points to "\\.host\Shared Folders\Root_of_C\Program Files (x86)\AdminStudio\2013\Repackager\Repack.exe"
As vinodmukka mentioned in the previous post, you should set the shortcut Start in folder to point to your AdminStudio Common folder. In my case it points to "\\.host\Shared Folders\Root_of_C\Program Files (x86)\AdminStudio\2013\Common\"
I would recommend using Repackager on your AdminStudio Client Tools machine for editing or building the .irp output into an .ism project file, .msi package, or virtual package...Use the Remote Repackager capture machine only for the Repackaging Wizard or OS Snapshot. But if you do want to perform editing/building activities on your Remote Repackager capture machine, be sure to create the following registry entry so that Repackager can locate your Exclusion List, etc.
Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\InstallShield\AdminStudio\12.0\
Note: If your Remote Repackager capture machine is 64-bit, the registry key should be HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\InstallShield\AdminStudio\12.0\
Value Name: Shared Location
Value Date: \\.host\Shared Folders\Root_of_C\Program Files (x86)\AdminStudio Shared\
(obviously point it to your AdminStudio Shared folder)
*Be sure that the registry key name points to 12.0 and not 11.5, otherwise it will not work.
BTW, I have not found it necessary to copy the Visual C++ 2008 SP1 x86 redistributable files to the Repackager folder*. And there is no need to copy over the Visual C++ 2005 x86 redistributable.
*Keep in mind that I don't perform the editing or project\package building on the capture machine. If you want to build a virtual package, Repackager would need some parts of the Visual C++ 2008 SP1 x86 redistrubtable.
One final note: On 64-bit Windows if you use a mapped drive instead of a UNC path, you may encounter an error when using the Repackaging Wizard's Installation Monitoring method. The error message is "InstallMonitor 64bit Launcher. LoadInjectionDriver failed. Error: 3" This does not happen on 32-bit Windows. It only happens on 64-bit Windows because it involves Windows security that Microsoft never included in 32-bit Windows.
The issue seems to be with UAC and security tokens and there are a number of ways to solve it:
1. Leave UAC turned on and click through the UAC prompt when the Repackaging Wizard launches. (Clicking through the UAC prompt provides you with the needed permissions to inject the Installation Monitoring)
or
2. Make the following two changes to the registry to disable UAC and auto-elevate everything:
Registry Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\
Registry Value 1: ConsentPromptBehaviorAdmin = 0
(DWORD)
Registry Value 2: EnableLUA = 1
(DWORD)
You need to disable UAC by setting these registry settings or using group policy. If you were to merely go to Control Panel > User Accounts > Change User Account Control Settings and disable UAC through the GUI, you are likely to see the above error message when using a mapped drive to point to Repack.exe. When you disable UAC via the Control Panel, it does turn off the UAC prompting but it doesn't auto-elevate every operation the way that it does when using the registry shown above. If you were to investigate the registry you would see that both ConsentPromptBehaviorAdmin and EnableLUA are set to 0, which leads to bad news for Installation Monitoring (at least in some cases, such as running Remote Repackager over a mapped drive.)
Which brings us to method #3 for avoiding the error:
3. Don't use mapped drive letters for your Remote Repackager shortcuts. Use UNC paths instead.
or
4. an earlier post mentioned copying the Repackager folder onto the capture machine. That will work, as it no longer uses mapped drives, but it's not really "Remote Repackager" at that point. It's pretty much Standalone Repackager. (Not that there's anything wrong with that. It just consumes a little more disk space)
Now before anybody jumps to the defense of mapped drives, I'm pretty sure there are situations where you could use a mapped drive successfully (without using my above listed solutions). It probably depends on the security rights of the account that it's mapped with. The real issue seems to boil down to security tokens. So if you love your mapped drives and don't mind UAC being completely disabled, just go with solution #2 and continue using your mapped drives.
Instead you can copy the C++ 2010 SP1 redistributable files to your Repackager folder (on your AdminStudio Client Tools machine, not your clean Remote Repackager capture machine)
If you need the VC++ 2010 SP1 files, download the Microsoft Visual C++ 2010 SP1 x86 redistributable from:
http://www.microsoft.com/en-us/download/details.aspx?id=5555
-Install it on one of your machines...but not on your Remote Repackager capture machine, as that would dirty it up. (or just take a VM snapshot prior to installing it and revert it later)
Although probably only a few of the following files are needed by Repackager, I would recommend copying all of the Visual C++ 2010 SP1 redistributable files to your Repackager folder:
atl100.dll
mfc100.dll
mfc100chs.dll
mfc100cht.dll
mfc100deu.dll
mfc100enu.dll
mfc100esn.dll
mfc100fra.dll
mfc100ita.dll
mfc100jpn.dll
mfc100kor.dll
mfc100rus.dll
mfc100u.dll
mfcm100.dll
mfcm100u.dll
msvcp100.dll
msvcr100.dll
vcomp100.dll
-If the OS is 64-bit, go to C:\Windows\SysWOW64\ and copy those files to your AdminStudio Client Tools Repackager folder.
By default, the Repackager folder on 64-bit machines is located at:
C:\Program Files (x86)\AdminStudio\2013\Repackager\
-If the OS is 32-bit, go to C:\Windows\System32\ and copy the C++ files to your AdminStudio Client Tools Repackager folder.
By default, the Repackager folder on 32-bit machines is located at:
C:\Program Files\AdminStudio\2013\Repackager\
On your Remote Repackager capture machine, all you need to do is create a shortcut that points to Repack.exe on your AdminStudio Client Tools machine. For example: On my VMware virtual machine I create a shortcut that points to "\\.host\Shared Folders\Root_of_C\Program Files (x86)\AdminStudio\2013\Repackager\Repack.exe"
As vinodmukka mentioned in the previous post, you should set the shortcut Start in folder to point to your AdminStudio Common folder. In my case it points to "\\.host\Shared Folders\Root_of_C\Program Files (x86)\AdminStudio\2013\Common\"
I would recommend using Repackager on your AdminStudio Client Tools machine for editing or building the .irp output into an .ism project file, .msi package, or virtual package...Use the Remote Repackager capture machine only for the Repackaging Wizard or OS Snapshot. But if you do want to perform editing/building activities on your Remote Repackager capture machine, be sure to create the following registry entry so that Repackager can locate your Exclusion List, etc.
Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\InstallShield\AdminStudio\12.0\
Note: If your Remote Repackager capture machine is 64-bit, the registry key should be HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\InstallShield\AdminStudio\12.0\
Value Name: Shared Location
Value Date: \\.host\Shared Folders\Root_of_C\Program Files (x86)\AdminStudio Shared\
(obviously point it to your AdminStudio Shared folder)
*Be sure that the registry key name points to 12.0 and not 11.5, otherwise it will not work.
BTW, I have not found it necessary to copy the Visual C++ 2008 SP1 x86 redistributable files to the Repackager folder*. And there is no need to copy over the Visual C++ 2005 x86 redistributable.
*Keep in mind that I don't perform the editing or project\package building on the capture machine. If you want to build a virtual package, Repackager would need some parts of the Visual C++ 2008 SP1 x86 redistrubtable.
One final note: On 64-bit Windows if you use a mapped drive instead of a UNC path, you may encounter an error when using the Repackaging Wizard's Installation Monitoring method. The error message is "InstallMonitor 64bit Launcher. LoadInjectionDriver failed. Error: 3" This does not happen on 32-bit Windows. It only happens on 64-bit Windows because it involves Windows security that Microsoft never included in 32-bit Windows.
The issue seems to be with UAC and security tokens and there are a number of ways to solve it:
1. Leave UAC turned on and click through the UAC prompt when the Repackaging Wizard launches. (Clicking through the UAC prompt provides you with the needed permissions to inject the Installation Monitoring)
or
2. Make the following two changes to the registry to disable UAC and auto-elevate everything:
Registry Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\
Registry Value 1: ConsentPromptBehaviorAdmin = 0
(DWORD)
Registry Value 2: EnableLUA = 1
(DWORD)
You need to disable UAC by setting these registry settings or using group policy. If you were to merely go to Control Panel > User Accounts > Change User Account Control Settings and disable UAC through the GUI, you are likely to see the above error message when using a mapped drive to point to Repack.exe. When you disable UAC via the Control Panel, it does turn off the UAC prompting but it doesn't auto-elevate every operation the way that it does when using the registry shown above. If you were to investigate the registry you would see that both ConsentPromptBehaviorAdmin and EnableLUA are set to 0, which leads to bad news for Installation Monitoring (at least in some cases, such as running Remote Repackager over a mapped drive.)
Which brings us to method #3 for avoiding the error:
3. Don't use mapped drive letters for your Remote Repackager shortcuts. Use UNC paths instead.
or
4. an earlier post mentioned copying the Repackager folder onto the capture machine. That will work, as it no longer uses mapped drives, but it's not really "Remote Repackager" at that point. It's pretty much Standalone Repackager. (Not that there's anything wrong with that. It just consumes a little more disk space)
Now before anybody jumps to the defense of mapped drives, I'm pretty sure there are situations where you could use a mapped drive successfully (without using my above listed solutions). It probably depends on the security rights of the account that it's mapped with. The real issue seems to boil down to security tokens. So if you love your mapped drives and don't mind UAC being completely disabled, just go with solution #2 and continue using your mapped drives.
Evan Border wrote:
It is not necessary for you to dirty your Remote Repackager machine with the Microsoft Visual C++ redistributables.
Instead you can copy the C++ 2010 SP1 redistributable files to your Repackager folder (on your AdminStudio Client Tools machine, not your clean Remote Repackager capture machine)
If you need the VC++ 2010 SP1 files, download the Microsoft Visual C++ 2010 SP1 x86 redistributable from:
http://www.microsoft.com/en-us/download/details.aspx?id=5555
-Install it on one of your machines...but not on your Remote Repackager capture machine, as that would dirty it up. (or just take a VM snapshot prior to installing it and revert it later)
Although probably only a few of the following files are needed by Repackager, I would recommend copying all of the Visual C++ 2010 SP1 redistributable files to your Repackager folder:
atl100.dll
mfc100.dll
mfc100chs.dll
mfc100cht.dll
mfc100deu.dll
mfc100enu.dll
mfc100esn.dll
mfc100fra.dll
mfc100ita.dll
mfc100jpn.dll
mfc100kor.dll
mfc100rus.dll
mfc100u.dll
mfcm100.dll
mfcm100u.dll
msvcp100.dll
msvcr100.dll
vcomp100.dll
-If the OS is 64-bit, go to C:\Windows\SysWOW64\ and copy those files to your AdminStudio Client Tools Repackager folder.
By default, the Repackager folder on 64-bit machines is located at:
C:\Program Files (x86)\AdminStudio\2013\Repackager\
-If the OS is 32-bit, go to C:\Windows\System32\ and copy the C++ files to your AdminStudio Client Tools Repackager folder.
By default, the Repackager folder on 32-bit machines is located at:
C:\Program Files\AdminStudio\2013\Repackager\
On your Remote Repackager capture machine, all you need to do is create a shortcut that points to Repack.exe on your AdminStudio Client Tools machine. For example: On my VMware virtual machine I create a shortcut that points to "\\.host\Shared Folders\Root_of_C\Program Files (x86)\AdminStudio\2013\Repackager\Repack.exe"
As vinodmukka mentioned in the previous post, you should set the shortcut Start in folder to point to your AdminStudio Common folder. In my case it points to "\\.host\Shared Folders\Root_of_C\Program Files (x86)\AdminStudio\2013\Common\"
I would recommend using Repackager on your AdminStudio Client Tools machine for editing or building the .irp output into an .ism project file, .msi package, or virtual package...Use the Remote Repackager capture machine only for the Repackaging Wizard or OS Snapshot. But if you do want to perform editing/building activities on your Remote Repackager capture machine, be sure to create the following registry entry so that Repackager can locate your Exclusion List, etc.
Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\InstallShield\AdminStudio\12.0\
Note: If your Remote Repackager capture machine is 64-bit, the registry key should be HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\InstallShield\AdminStudio\12.0\
Value Name: Shared Location
Value Date: \\.host\Shared Folders\Root_of_C\Program Files (x86)\AdminStudio Shared\
(obviously point it to your AdminStudio Shared folder)
*Be sure that the registry key name points to 12.0 and not 11.5, otherwise it will not work.
BTW, I have not found it necessary to copy the Visual C++ 2008 SP1 x86 redistributable files to the Repackager folder*. And there is no need to copy over the Visual C++ 2005 x86 redistributable.
*Keep in mind that I don't perform the editing or project\package building on the capture machine. If you want to build a virtual package, Repackager would need some parts of the Visual C++ 2008 SP1 x86 redistrubtable.
One final note: On 64-bit Windows if you use a mapped drive instead of a UNC path, you may encounter an error when using the Repackaging Wizard's Installation Monitoring method. The error message is "InstallMonitor 64bit Launcher. LoadInjectionDriver failed. Error: 3" This does not happen on 32-bit Windows. It only happens on 64-bit Windows because it involves Windows security that Microsoft never included in 32-bit Windows.
The issue seems to be with UAC and security tokens and there are a number of ways to solve it:
1. Leave UAC turned on and click through the UAC prompt when the Repackaging Wizard launches. (Clicking through the UAC prompt provides you with the needed permissions to inject the Installation Monitoring)
or
2. Make the following two changes to the registry to disable UAC and auto-elevate everything:
Registry Key Name: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\Policies\System\
Registry Value 1: ConsentPromptBehaviorAdmin = 0
(DWORD)
Registry Value 2: EnableLUA = 1
(DWORD)
You need to disable UAC by setting these registry settings or using group policy. If you were to merely go to Control Panel > User Accounts > Change User Account Control Settings and disable UAC through the GUI, you are likely to see the above error message when using a mapped drive to point to Repack.exe. When you disable UAC via the Control Panel, it does turn off the UAC prompting but it doesn't auto-elevate every operation the way that it does when using the registry shown above. If you were to investigate the registry you would see that both ConsentPromptBehaviorAdmin and EnableLUA are set to 0, which leads to bad news for Installation Monitoring (at least in some cases, such as running Remote Repackager over a mapped drive.)
Which brings us to method #3 for avoiding the error:
3. Don't use mapped drive letters for your Remote Repackager shortcuts. Use UNC paths instead.
or
4. an earlier post mentioned copying the Repackager folder onto the capture machine. That will work, as it no longer uses mapped drives, but it's not really "Remote Repackager" at that point. It's pretty much Standalone Repackager. (Not that there's anything wrong with that. It just consumes a little more disk space)
Now before anybody jumps to the defense of mapped drives, I'm pretty sure there are situations where you could use a mapped drive successfully (without using my above listed solutions). It probably depends on the security rights of the account that it's mapped with. The real issue seems to boil down to security tokens. So if you love your mapped drives and don't mind UAC being completely disabled, just go with solution #2 and continue using your mapped drives.
Good workaround so far... however If you copy the common folder onto a shared location and create the following reg key on your capturing machine the problem is also solved:
Windows Registry Editor Version 5.00
[HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows\CurrentVersion\App Paths\islc.exe]
@="\\\\Path\\To\\Repackager\\islc.exe"
"Path"="\\\\Path\\To\\Common\\Folder"
