I like to write on PowerShell from time to time. These are mainly administrative and deployment tasks. In this post I want to talk about solving one interesting problem related to the work of the
WebAdministration module. So, the crux of the problem: when executing any cmdlet from this module, an error occurs:
Cannot retrieve the dynamic parameters for the cmdlet.
Retrieving the COM class factory for component with CLSID {688EEEE5-6A7E-422F-B2E1-6AF00DC944A6} failed due to the following error: 80040154.
The script runs on 64-bit Windows 7. And this is the key point. But before proceeding to the description of the solution, I would like to say a few words about the infrastructure in which PowerShell scripts are used. The most commonly used scripts (for example, creating and configuring a local site, creating queues, etc.) are designed as module functions. This module can be loaded by the developer into PowerShell session and use the functions exported by him in the console. But just for them wrappers are made in the form of batch-files, so that they can be launched just by clicking. When using them, this problem was discovered. BUT only provided that the batch file is launched from Total Commander.
An example of a command that calls the Get-WebSite cmdlet to display a list of all local sites:
powershell -noexit -command "& { Import-Module WebAdministration; Get-WebSite }"
* This source code was highlighted with Source Code Highlighter .
Let's save it to a file and try to launch it from the explorer. With the “-noexit” flag, the session will not end after executing the command and we will have time to analyze the running process using
Process Explorer . We saw a list of local sites, and in Process Explorer looked at the properties of the process:
')


Well, it looks good. Now let's try to run the same batch file in Total Commander:


When the 64-bit version of Windows was released, the libraries that existed before were not renamed. They were adapted, recompiled and left to live in the% windir% \ System32 directory. Their 32-bit counterparts were moved to the% windir% \ SysWOW64 directory. Now, when a 32-bit process tries to access files in% windir% \ System32, the
system automatically redirects the call to% windir% \ SysWOW64. If the 32-bit process needs access to the% windir% \ System32 directory, it can access it through the alias% windir% \ Sysnative. Such a call will not be forwarded.
Running the script from Total Commander, we are launching a 32-bit version of PowerShell, for which the WebAdministration module is not registered correctly for some reason. Or can it be registered for only one architecture? Unfortunately, I could not find the exact reasons.
However, we have valuable information. You can, using% windir% \ Sysnative, run the version of PowerShell we need and use all the features of WebAdministration. But note that% windir% \ Sysnative exists only in a 32-bit process. The final batch file takes the form:
if not exist %windir%\Sysnative\nul goto 64bit
set ps= "%windir%\Sysnative\WindowsPowerShell\v1.0\powershell.exe"
goto start
:64bit
set ps= "%windir%\System32\WindowsPowerShell\v1.0\powershell.exe"
:start
%ps% -noexit -command "& { Import-Module WebAdministration; Get-WebSite }"
* This source code was highlighted with Source Code Highlighter .
Such a script will run 64-bit PowerShell from TotalCommander, from Far, and from Explorer (that’s what we managed to check). In a 32-bit OS, there will be no problems either.
A few notes:
Note 1 . Instead of using the WebAdministration module, you can use ServerManager from the Microsoft.Web.Administration assembly. You can read about the use in this
article .
Note 2 . Perhaps Total Commander is configurable in such a way that it runs% windir% \ System32 \ cmd.exe, but I haven’t found such options.
Note 3 . This is not a local problem, since The error appeared on all network machines on which I tried to run the script. I am far from administering local area networks, may be affected by some settings in the domain?
Thanks for attention!