In which Lync forces me to dig into the Exchange world again…..
I got an excellent question as a followup to my post breaking down the exchucutil.ps1 script in excruciating detail.
The questions by user “soder” basically asked if the –verify switch was still valid in the Exchange 2010/2013 versions of the script. In short – no. In long – mostly no.
Looking at the script, the following is seen on line 10:
param($Forest = $null,[Switch]$Verify)
This means that the script is looking for a command line parameter named -Verify. Running the script with the -Verify parameter runs the script in “verify mode”. (The [Switch] construct basically means that if -verify is present, set the $verify variable to $True, else set it to $false).
However, something strange happens a few lines down – line 21 to be exact:
$Verify = $false;
This sets $Verify to $false NO MATTER WHAT you set on the command line. So effectively, $Verify is disabled.
I don’t have any idea why this is done but there must be a good reason. I don’t want to speculate.
However, if you want to run a verify pass anyway, comment out line 21. Then run exchucutil.ps1 -verify. I ran it in my lab and I got a list dumping out the permissions and not attempting to actually make changes.
Note that with the -Verify parameter that the script ends before making any changes.
Microsoft effectively removed the verify permissions. (Well, it could be an oversight. It probably is….)
In summation, as of at least Exchange 2013 (and maybe 2010) verify does not officially work anymore.
3 comments
Thanks for the update. The reason I was so seriously asking this, that I was running the script some time ago in a large environment with the -verify switch, many-many UM servers disctributed across the globe and many UM dialplans with many OCS/Lync pools. Actually it was a distributed exchange 2010 system. I used to provide that switch since the Exchange 2007 days. However, I was very surprised, when the script in fact went into write mode, and without any question asked, it assigned all the dialplans for all the UM servers it could found, creating a huge mess. It didnt take much getting my a$$ kicked, as the result was practically that all UM servers was allowed to receive calls for each of the dialplan, creating huge traffic among distant datacenters. Fortunately the IT guys managed to roll back quite soon, but I learned the lesson nevertheless. I was just so pissed off, that MS couldnt properly document that damn script, like as if it was a huge miracle it was doing.. Thanks once again clearing this out, all those mighty MVPs were just looking at me stupid, when I asked them about this.
BTW – the reason our company reverse engineered this is for that exact reason – we can’t be having random dial plans scattered around the globe and expect things to work. So a colleague broke down the scripts about 2 years ago and set everything up to work manually. There are a lot of new employees who didn’t know exactly how it worked so I sat down, figured it out, and passed the info along for a peer review. Now we know how our network is set up and, despite potential MS protests, it works fabulously.
BTW – the reason our company reverse engineered this is for that exact reason – we can’t be having random dial plans scattered around the globe and expect things to work. So a colleague broke down the scripts about 2 years ago and set everything up to work manually. There are a lot of new employees who didn’t know exactly how it worked so I sat down, figured it out, and passed the info along for a peer review. Now we know how our network is set up and, despite potential MS protests, it works fabulously.