Hi luc,
i have following scenerio where i see powercli 6.5 in control pannel which seems to be installed by msi
at the same time i have 11.2 also and i dont see any modules in default directory
iam willing to upgrade but for some reasons online wont work .do i need to uninstall 6.5 for offline upgrade .
not sure how 11.2 modules come from??
i dont think it should be the case as thhis is equivalent to uninstaling the way we do throuh control panel .
and it .msi packge not the modules that started with 6.5.1 while im uninstalling 6.5.0.
Some of the DLLs are the same in both PowerCLI versions.
If one of those is loaded, the uninstall will not be able to remove it.
The only option it has to schedule that removal at the next reboot.
Hence the request for a reboot.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
reboot has been requested as per yur command
Hi Luc ,
server was rebooted and powercli 6 (.msi) has been removed
i m now removing old powercli 11.2 but unable to remove following four
Looks like there PS sessions with those modules loaded.
Stop all PS sessions
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
i have already done .exit all pssessions
Did you logoff/logon? To stop ghosted sessions.
Or even a power off/power on?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
Otherwise you have to use SysInternals handle tool.
It should show who has a file open
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
i exited powershell
and stopped all powershell processes
however now i have copied offline modules .but autoloading is not working
i m checking
$PSModuleAutoLoadingPreference
Did you also check $env:PSModulePath?
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
i copied here this is where all old modules were present .and this is one of the paths
C:\Windows\System32\WindowsPowerShell\v1.0\Modules
If that path is in $env:PSModulePath the autoload should work.
It may take a bit before the PS cache that it uses for autoload is rebuilt.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
few days back tested this on one the systems it was wotking not today its not .
You seem to have some very 'funny' systems there :smileygrin:
Without actually looking at the environment, it is hard to determine what might go wrong.
Some general tips:
- use the Verbose switch
- check $env:PSModulePath
- try to load the module with the full path to the module's .psd1 file
- try the Import-Module from different PS versions (if you have them installed side-by-side)
- check the PS eventlogs (when on Windows) or the logs documented in about_Logging_Non-Windows
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
it is a straightforward process also i tested on one of the machines before going futher .
one of the blogs from kyle rudy says sometimes saving module on online sytem with powershell 5 causes issues ans someone raises this issue earlier .
so they recommend to save on online sytem with powershell 4 .now its hard to find powershell 4 .as its hard to find things we desire ...
i might be court martialed for this ..
That problem you are referring to is when you do Save-Module on a PSv5 platform and wanted to install those modules on a PSv4 platform.
The reason was the extra folder with the version.
PSv5 to PSv5 should not be a problem.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
i am checking one more time .
The most common scenario we’ve come across is where the ‘Save-Module’ cmdlet was used with an online system that has PowerShell version 5.x. When this happens, there are an additional level of folders created between the top-level module folder and the module files themselves.
this is from vmware blog only
PowerCLI Offline Installation Walkthrough - VMware PowerCLI Blog
this is working now i was saving old and new mods file in desktop also so i moved to one of the $env:psmodulepath and its working .
And?
This just confirms my earlier statement that PSv5 to PSv5 should not have an issue.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference