| T O P I C R E V I E W |
| mitachu |
Posted - 05/30/2012 : 09:24:48 AM
Powershell seems to take ages to open up on some servers. Is there something I can be looking at? I don't think these servers are going to have a profile that's being loaded and taking a long time as they're often fresh installs.
|
| 10 L A T E S T R E P L I E S (Newest First) |
| JeffWouters |
Posted - 05/31/2012 : 04:00:53 AM
Indeed, check your profiles... also check what's in them, one of my colleagues had one consisting of more than 700 lines :-S |
| jhicks |
Posted - 05/30/2012 : 11:13:05 AM
You might want to double-check and verify there are no profiles. Run this command and see if any of these are true:
PS S:\> $profile.CurrentUserAllHosts, $profile.CurrentUserCurrentHost, $profile.AllUsersAllHosts, $profile.AllUsersCurrentHost | test-path |
| mitachu |
Posted - 05/30/2012 : 10:41:22 AM
quote:
Originally posted by Playwell
If the workstation has no direct internet access unmark this option in IE:
'Check for publisher's certificate revocation' under advanced
Yep, done that already. The server has Internet access but I thought I'd give it a shot anyway.
|
| Playwell |
Posted - 05/30/2012 : 10:25:51 AM
If the workstation has no direct internet access unmark this option in IE:
'Check for publisher's certificate revocation' under advanced |
| jhicks |
Posted - 05/30/2012 : 10:17:06 AM
That looks right. If PowerShell is still slow to open, then something else is going on. Could this be as simple as needing to defrag the disk? |
| mitachu |
Posted - 05/30/2012 : 10:08:25 AM
I just ran that on my laptop after running the first suggestion and got the following output:
PS C:\Users\tim.wiser\Documents\Work\n-able\n-able scripts by me> .\OptimisePowerShell2.ps1
Already GAC'ed: Microsoft.PowerShell.Commands.Diagnostics.dll
Already GAC'ed: Microsoft.PowerShell.Commands.Management.dll
Already GAC'ed: Microsoft.PowerShell.Commands.Utility.dll
Already GAC'ed: Microsoft.PowerShell.ConsoleHost.dll
Already GAC'ed: Microsoft.PowerShell.Security.dll
Already GAC'ed: Microsoft.WSMan.Management.dll
Already GAC'ed: mscorlib.dll
Already GAC'ed: System.Configuration.Install.dll
Already GAC'ed: System.Core.dll
Already GAC'ed: System.Data.dll
Already GAC'ed: System.DirectoryServices.dll
Already GAC'ed: System.dll
Already GAC'ed: System.Management.Automation.dll
Already GAC'ed: System.Management.dll
Already GAC'ed: System.Transactions.dll
Already GAC'ed: System.Xml.dll
PS C:\Users\tim.wiser\Documents\Work\n-able\n-able scripts by me>
Perhaps it does the same thing?
|
| jhicks |
Posted - 05/30/2012 : 10:03:37 AM
Periodically I do this on my Win7 box and have noticed an improvement in load time. This is the script I use:
#requires -version 2.0
Set-Alias ngen (Join-Path ([System.Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()) ngen.exe)
[AppDomain]::CurrentDomain.GetAssemblies() |
Where {$_.Location} |
sort {Split-path $_.location -leaf} |
%{
$Name = (Split-Path $_.location -leaf)
if ([System.Runtime.InteropServices.RuntimeEnvironment]::FromGlobalAccessCache($_))
{
Write-Host "Already GAC'ed: $Name" -fore CYAN
}else
{
Write-Host -ForegroundColor Yellow "NGEN'ing : $Name"
ngen $_.location | %{"`t$_"}
}
}
|
| Xenophane |
Posted - 05/30/2012 : 09:58:19 AM
I have not experienced problems with it... But on the other hand I have not done this large scale in our server environment either, since most time I use my local machine or a jump host. |
| mitachu |
Posted - 05/30/2012 : 09:36:50 AM
Thanks for that.
I take it this can cause problems?
|
| Xenophane |
Posted - 05/30/2012 : 09:27:38 AM
PowerTip of the Day, from PowerShell.com:
Optimizing PowerShell Performance
PowerShell is loading .NET assemblies. These assemblies can be precompiled using the tool ngen.exe which improves loading times (because the DLLs no longer have to be compiled each time they are loaded).
Before you think about optimizing the DLLs PowerShell uses, you should do some reading on ngen.exe and its benefits. Then, you could use the following code to optimize all DLLs loaded by PowerShell. You do need Administrator privileges for this.
$FrameworkDir=[Runtime.InteropServices.RuntimeEnvironment]::GetRuntimeDirectory()
$NGENPath = Join-Path $FrameworkDir 'ngen.exe'
[AppDomain]::CurrentDomain.GetAssemblies() |
Select-Object -ExpandProperty Location |
ForEach-Object {
& $NGENPath """$_"""
} |
