Quantcast
Channel: dbailey's blog
Viewing all articles
Browse latest Browse all 16

Import-PSSession and temp files

$
0
0

One of the reasons I use a custom PowerShell profile is to make things available no matter how or where I’ve launched PowerShell. For instance, I like to use the ISE and I work on Exchange. Instead of having to launch the Exchange Mangement Shell shortcut for Exchange 2007, I added code in my profile to check for the existence of the necessary snap-ins and load them if they existed. That way, as long as my documents were redirected and the tools were installed on the machine, the Exchange cmdlets were at my fingertips.

Exchange 2010 changed things quite a bit. Now everything is a remote PowerShell session. When I updated my profile for Exchange 2010, I did a minimalist deconstruction of what the Exchange Management Shell shortcut was doing and added this code:


Import-Module ActiveDirectory

function Load-Exch2010Session {
    $EXCASes = get-adcomputer -Filter {[blah]} -SearchBase "[blah]"
    $EXCAS = $EXCASes | random | select-object -ExpandProperty Name
    $EXSession = New-PSSession -ConfigurationName Microsoft.Exchange -ConnectionUri http://$EXCAS/PowerShell/ -Authentication Kerberos
    Import-PSSession $EXSession > $null

}

That worked adequately and since it was remoting, I didn’t even need the Exchange management tools installed locally.

Then, recently I was in the process of migrating to a new desktop machine when I discovered a problem. I was using WinDirStat and noticed the temp directory for my admin account was rather large and had an interesting pattern. Browsing to the folder, I saw this:

Temporary implicit remoting module folders

And, inside each of those folders was this:

Temporary implicit remoting module files: ps1xml, psd1, psm1

Looking at the content of those files made it obvious that they were from my Exchange PowerShell remoting. The interesting pattern in WinDirStat was from the repetition of the file types. I wish I had noted the number and time span of them to get an estimate of how often I load Exchange sessions.

But, I deleted all of them and fired up a new PowerShell session. Sure enough, a new set of temp files was created. I closed PowerShell and they didn’t get cleaned up. Next, I launched the Exchange Management Shell. No temp files were created. Hmm, maybe the Exchange team put all that code into the shell startup for a reason…

Next I tried loading the session the way I had been and I tried Remove-PSSession. Sure enough, it cleaned up the temp files. So, I started digging for a way to run some code before I closed PowerShell to remove any open sessions. Something alagous to a profile but that runs upon exiting. I think it’s probably doable but I didn’t find a suitably elegant solution quickly.

So, I took a closer look at RemoteExchange.ps1 that the shortcut calls. I see that it calls CommonConnectFunctions.ps1 and the majority of it is dedicated to caching and reusing the PowerShell modules instead of using the temp remoting modules. It keeps hashes and stores file locations at HKCU:Software\Microsoft\ExchangeServer\v14\RemotePowerShell\$serverName and stores the modules at $env:APPDATA\Microsoft\Exchange\RemotePowerShell\$serverName.

So, I took the relevant code, stripped anything that referenced files that are installed with the management tools (really just $CommonConnectFunctions_LocalizedStrings) and kept my code to select a random CAS server.

The lesson here is to clean up if you import remote sessions. I don’t necessarily recommend doing what I do as far as stripping the Exchange remoting code down because there may be additional unintended consequences and Microsoft may change something with service packs and such.


Viewing all articles
Browse latest Browse all 16

Trending Articles