How often is it that a feature is also a right pain in the …..
I ran an audit script today and half way through it started throwing loads of red error messages. Now red is a nice colour, Ferraris are red but when it comes to PowerShell the less red we see the better :-).
Any way I could have avoided the errors better in my code but this script has been in use for years with no issues so I wondered why it was suddenly complaining.
In short it was because the script was picking up the last connection I had established with the quest commandlets.
It’s a “feature” that once you establish a connection the subsequent commands use the same connection. The problem with this is that not every command you use will return what you need. For example suppose I connect to domain A and query a user then without establishing another connection I just query for a user in Domain B. Guess what? One of two things will happen. If the same username exists in Domain A then you just bound to the wrong object and are possibly on your way to a career limiting mistake. The second thing that could happen is if no matching username is in Domain A your script will not be able to bind and make the changes and you could be on your way to a career limiting mistake …. ARRRRRGHHHH.
OK it’s unlikely you will get into any serious trouble here but you might so I’ve realised now that because of this feature you need to make sure you always specify the connection you want to use explicitly.
That means always use the -connection parameter on the commands that will accept it and establish a connection to the correct domain / ARS service and store this in a variable. This will make your script portable between domains and also allow you to use multiple domains in the same script.
I’ve now modified my get-AdminCredentials function and combined it with my post on using a hash table to store the domain connection objects.
clan8blog 