In a Web server installer that I’m maintaining, we keep track of whether or
not the installer had installed IIS 7 and/or ASP (under Vista or later) and
save an appropriate value to the Registry if so. During an uninstall, if that
value is there and no other Web sites are using IIS on that machine, the user
is asked whether or not IIS/ASP is to be removed. If so, we remove whatever
we installed.
The following is the command that we launch in order to remove IIS 7 and ASP
(line breaks added for clarity):
C:\Windows\system32\pkgmgr.exe /norestart /uu:IIS-WebServerRole;
IIS-WebServer;IIS-CommonHttpFeatures;IIS-StaticContent;
IIS-DefaultDocument;IIS-DirectoryBrowsing;IIS-HttpErrors;
IIS-ApplicationDevelopment;IIS-ASP;IIS-ISAPIExtensions;
IIS-HealthAndDiagnostics;IIS-HttpLogging;IIS-LoggingLibraries;
IIS-RequestMonitor;IIS-Security;IIS-RequestFiltering;
IIS-HttpCompressionStatic;IIS-WebServerManagementTools;
IIS-ManagementConsole;WAS-WindowsActivationService;
WAS-ProcessModel;WAS-NetFxEnvironment;WAS-ConfigurationAPI
This works fine on 32-bit systems but does not work at all on 64-bit
systems, even with WOW64 redirection disabled. (Ignore the /norestart
parameter, as the installer does a reboot at the end of the install if
necessary.) I’ve even tried entering this command into an admin-level command
prompt (without the /norestart parameter), but to no avail.
The command that we use during the install to install IIS 7/ASP is similarly
long, and it always works, so I can’t imagine that the problem is that the
uninstall command line is too long. (To test that theory, I even tried
breaking the command into two commands, one to remove the ASP components only
followed by one to remove the rest. Same problem, nothing was removed.)
Is there some other command that would do what we want on 64-bit systems? If
so, do we have to disable WOW64 redirection, and will it also work on 32-bit
systems? (It will only be called on Vista and later systems. On earlier
systems, we rely on the user making sure that IIS and ASP are pre-installed.)
As it turns out, the problem that I was having doesn’t have anything to do with pkgmgr.exe, unless you want to count lack of patience when doing a manual test to see why it wasn’t working. In the installer, the problem was the install script doing something that prevented the command from getting launched. In the case of the manual tests, I just wasn’t waiting long enough for the command to finish running. (It takes about a couple of minutes, in the case of the above command line.)