February 12, 2015 at 12:56 pm #22562
Devin L. GangerParticipant
I'm writing some long-lived Exchange PowerShell connections for Exchange 2013 and Exchange Online for a customer doing a large migration. We have a problem with a flaky network that will randomly cause the remote PowerShell sessions to drop, and these always cause my scripts to run haywire and need to be restarted — either because we start getting assorted error messages for several minutes before the session itself drops, or because the session does finally drop, the next cmdlet in the script attempts to re-establish the implicit session and hangs on requesting credentials. And because it's a multi-domain forest, if it's the on-premises Exchange session that drops, we start getting failures because the re-established session loses the Set-ADServerSettings -ViewEntireForest value and defaults back to the local domain.
These scripts are meant to be run in long-lasting sessions on a central management server. I've stored the credentials in global variables (so they can be reused between scripts — the operators must provide them when they open PowerShell up and kick the scripts off) and have figured out how the scripts can detect if there's a currently open session they can use (to avoid the overhead of setting up/tearing down the connection). However, I cannot figure out how to:
1) Detect when there's an error with the session
2) Re-establish the session using the stored credentials instead of popping up a request for new ones
3) Re-run Set-ADServerSettings as soon as the session is re-established
Does anyone have any pointers to resources that can help me figure out how to accomplish these tasks?
Thanks in advance.
February 12, 2015 at 2:57 pm #22567
I think you'd probably need to write a module that includes commands that wrap around the -PSSession commands, possibly even proxying them. That way, YOUR commands can take the initial step of verifying/reconnecting, prior to running the "real" underlying command. You could store credentials in a module-level variable, for example. Apart from doing that as unique commands and/or proxy commands (functions), I don't think you could wedge that functionality in any other way.
You'd also potentially need to deal with the fact that rehydrating the session is actually just spinning up a new one, meaning any prior state would be lost. So this wouldn't work if Command B ran, had to reconnect, and didn't realize that Command A had never run in that new session – if that makes sense. There's no way to "save state" in the remote session and spin up a replacement session that has the same state as an old, now-discontinued one.
February 12, 2015 at 3:03 pm #22568
I mean, alternately, I supposed you could grab the proxy function module that Implicit Remoting generates, hack the extra code into it, and then save it as an explicit module. Not sure how hard that would be.
You must be logged in to reply to this topic.