I have updated PowerCLI to 4.0 update 1 on couple servers and on both systems PowerCLI shell startup is extremely slow, it takes like 5 minutes to get prompt when it took less than 30 seconds on last version. Both systems are Windows 2003 Standard 32-bit SP 2, .net 3.5 SP 1 and PowerShell 1.0 installed.
Anyone else seeing this?
Mine are a similar setup and starting just as fast as the last version, what happens if you start a normal powershell session does that take a while ?
If you start a normal session and then load the snapin does that take just as long ?
From the normal powershell session use: add-pssnapin VMware.VimAutomation.Core
If you found this information useful, please consider awarding points for Correct or Helpful.
Alan Renouf
Powershell itself starts quickly, it is loading of PowerCLI components that take a loong time.
Since you are running PowerShell v1 it could be the ngen bug that you see.
Try the advice in Speeding Up PowerShell Startup, or even better upgrade to PowerShell v2 where this installation bug is fixed.
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
I noticed same behavior..powershell opens in a flash, and it takes about a minute to load vmware snapin..tried ngen fix, but of no use
Get-PSSnapin -r vmware* | Add-PSSnapin
Upgrading to PowerShell v2 did not help, vSphere snapin startup delay is still there.
Same problem here, some systems work without any problem and others are extremely slow.
On systems with the problem, PowerShell itself starts in a blink of an eye, but it takes about 5 minutes to add the snapin (while the system seems to be doing nothing). On one ore two systems it helped when I removed PowerCLI and PowerShell, then upgraded .NetFramework, then installed PowerShell v2 and PowerCLI 4 U1. But on the citrix farm, where I realy need it, nothing seems to help.
lets wait for Mr.Carter's blessing
I've asked the dev and QA teams to chime in and give any advice they have, so we'll see what their input is.
ISTR a back in the days of 1.0 there was a slow startup on 64 bit unless you had installed .NET 2 SP1. I don't know if that still applies, which is why I asked the team to have a look.
=====
Carter Shanklin
Read the PowerCLI Blog
[Follow me on Twitter|http://twitter.com/cshanklin]
As you noted, the problem probably occurs depending on environment setup/configuration. So I'll try to figure out what's common in all the environments where the problem was seen.
Those who see the problem, can you tell me the following details about the machine on which PowerCLI 4.0 U1 startup is slow:
- OS version, including whether it's 32 or 64 bit
- OS service pack installed, if any
- PowerShell version in which the problem reproduces
- .Net 2.0 service pack installed, if any
- While you're waiting for PowerCLI to start, what's the CPU usage? Is there a process which seems to be eating most of the time of one of the CPU cores? Which process?
Disable "Check for publisher's certificate revocation" in Internet Explorer. This might speed up PowerCLI setup and startup if the machine does not have Internet access.
VCpaul,
Thanks to you're suggested setting everything works like a charm now!!
Thank you for the feedback. I hope Andrey reads this. The problem also exists in many other products, for example some Citrix consoles and DataCore SANmelody.
Thanks for the hint VCPaul - it helps a lot. Right now I'm trying to break a system in the right way to reproduce the issue
That setting work for everything .dot net related.
We had this problem also, because we are in a restricted network and we don't have internet access.
In addition to your setting, we also create the following entry in the hosts file:
127.0.0.1 clr.microsoft.com
That means we'll be seeing v4 of your PowerPack a lot faster
Blog: lucd.info Twitter: @LucD22 Co-author PowerCLI Reference
That means we'll be seeing v4 of your PowerPack a lot faster
</div>
Yep, half the time now
If you found this information useful, please consider awarding points for Correct or Helpful.
Alan Renouf
I wanted to add an additional option for disabling the stated option above via a powershell.exe.config file. For me the setting listed above didn't help in a specific situation where I was launching powershell as the SYSTEM user.
If you are having problems with as listed above but don't want to set a group policy or are using a background user for Powershell try the following.
Create a file called powershell.exe.config with the following in it.
<?xml version="1.0"?>
<configuration>
<runtime>
<generatePublisherEvidence enabled="false"/>
</runtime>
</configuration>
And place it in the following locations:
c:\windows\system32\windowspowershell\v1.0
c:\windows\syswow64\windowspowershell\v1.0