I am using WASP successfully with PowerShell 64 bits, but I need to use PowerShell 32 bits cause of OCR MODI.Document.
But my PowerShell x86 is not able to load my WASP module :
See when I am trying to reach WASP module
How is it possible? I've run both with administrator account ...
I've never seen that--I gave rights to everyone, but I can't reach my folder Right for folder WASP
For module to be accessible from both x86 and x64 PS, it should be in:
$Home\Documents\WindowsPowerShell\Modules (%UserProfile%\Documents\WindowsPowerShell\Modules)
$Env:ProgramFiles\WindowsPowerShell\Modules (%ProgramFiles%\WindowsPowerShell\Modules)
You shouldn't install modules in
$PSHome\Modules (%Windir%\System32\WindowsPowerShell\v1.0\Modules)
because
This location is reserved for modules that ship with Windows. Do not
install modules to this location.
See this document: Installing a PowerShell Module.
Here is screenshot of ProcMon, showing that x86 PS doesn't look into the x64 module directory when trying to import module:
Related
I need to install PSReadline module in an offline computer
with
Windows 7 SP1
and powershell 5.1
I have another computer that is connected to the internet.
Could you please explain how to download the relevant files
and how to install them on the offline computer?
If you download it to an online computer the module will be in one of your module paths - type:
$env:PSModulePath
...this will list all the possible paths, just search for the correct folder and copy it to the offline computer in one of its module paths. If there are any dependencies these will need to be copied also.
I have installed a WebServer 2008 R2 Core version and I'm trying to configure it to be remotely managed from another server in the domain I need to import the WebAdministration module According to the steps exposed in this article
http://www.iis.net/learn/install/installing-iis-7/install-and-configure-iis-on-server-core
using the Import-module WebAdministration it gives me the specified module 'WebAdministration' was not loaded because no valid module file was found in any module directoryAt line1 char 14. I executed the command Get-Module -ListAvailable and returned 4 module types
BestPractices, BitsTrabsfer, PSDiagnostics and ServeManager
I read the other threads about the issue none of them is consistent and proposes a good solution to that. BTW is there a way to let the server download the requested modules form microsoft repository if not found. Any consistent proposal to solve this will be appreciated
Is the IIS PowerShell Snap-In installed? If not, you can download the 32-Bit version or the 64-Bit version. After you run the MSI (using msiexec /i, since this is core), the snap-in should be registered and can be invoked via import-module or
& "$env:programfiles\IIS\PowerShellSnapin\iisConsole.psc1"
On Windows 7 I installed Web Platform Installer from
https://www.microsoft.com/web/downloads/
On the start menu search for "web" to make the app visible.
Then using Web Platform Installer ... Install IIS: Management Scripts and Tools
Make sure that the IIS is installed and configured properly
I'm trying to install MCR on a virtual machine, Windows server 2012 (that doesn't have MATLAB).
I manage to send the file over and run the installation program.
It installs with no problem.
But then I still get:
Could not find version 8.1 of the MCR
Anyone has an idea?
I tried to do it as administrator as well, but doesn't matter.
Can I change some path or something manually?
The error message is also:
attempting to load mclmcrrt8_1.dll
On the machine you used to build the standalone, get the correct MCR version with the following command:
>> mcr
The WIN64 MCR Installer, version 8.2, is:
C:\Program Files\MATLAB\R2013b\toolbox\compiler\deploy\win64\MCRInstaller.exe
MCR installers for other platforms are located in:
C:\Program Files\MATLAB\R2013b\toolbox\compiler\deploy\<ARCH>
<ARCH> is the value of COMPUTER('arch') on the target machine.
Full list of available MCR installers:
C:\Program Files\MATLAB\R2013b\toolbox\compiler\deploy\win64\MCRInstaller.exe
For more information, read your local MCR Installer help.
Or see the online documentation at MathWorks' web site. (Page may load slowly.)
Take the file it names and install it on the server. You must match the architecture too.
Here are links to the installers.
When I do this -
PS C:\> $env:psmodulePath.split(";")
I get two folders - i.e. User Module Folder and System Module Folder.
User Module Folder
C:\Users\winUser1\Documents\WindowsPowerShell\Modules
System Module Folder
C:\Windows\system32\WindowsPowerShell\v1.0\Modules\
Now, when I am copying my psm1 files under system module folder, and trying to do import-module from ISE x86, the scripts are not getting loaded, but vice-versa is true - i.e. working from user module folder.
But, in a production environment, I want any user to be able to execute the scripts. Any idea how to achieve the same ?
NOTE: I am using Windows 2008 R2 and Windows 7 - All 64-Bit Versions, but scripts should run as 32-bit version
Try to copy them under the SysWOW64 folder. The SysWOW64 folder contains the 32-bit system files and the System32 contains the 64-bit system files
C:\windows\SysWOW64\WindowsPowerShell\v1.0\Modules
I am trying to use a 32 bit wix installer to install to the powershell directory c:\windows\????\windowspowershell\v1.0
i have hard coded the 32bit directory
and i am trying to read the registry to return the 64 bit location.
all works fine on a 32bit machine, the registry gets read with the correct value and the file is installed to the correct place.
however when running on a 64bit machine (server 2008 R2) the registry picks up the correct 64 bit location but my hard coded 32 bit location is overwritten with the 64 bit registry value.
what is going on?
is there a better way of doing this?
what i have is a single ps1 script that needs to be installed to the powershell directory, if there is a 64 bit and 32 bit directory the same file should be copied to both locations
thanks
James
Windows Installer was designed to be platform specific. X86 packages can only write to X86 locations and X64 packages can only write to X64 locations. There are some hacks that allow you to get around this but they aren't supported. The official Microsoft solution is to create multiple MSI's and use a bootstrapper to chain them together ( ugly ) but you can also use a custom action to copy the file to the secondary location.
Sorry, no good solutions on this one IMO.