How to Infrastructure.

While I know Exchange 2016 has been released, some of you may have just succeeded in your year long badgering campaign to convince the higher ups to move to Exchange 2013 and get off of Exchange 2007, 2010, or God forbid Exchange 2003.  If it's the latter, then you have my heart felt sympathies - both because you were stuck on that for all this time and for the amount of work your gonna need to do to get to Exchange 2013 Well, assuming you were persuasive enough and they did in fact agree to let you go to 2013, this post might be of help.  As all good little admins should, I built a dev environment and ran through the upgrade process.  I fine tuned the steps as I went and got my list down.  Confidence was brimming. Servers were created, storage provisioned, and change controls logged.  With a quiet anticipation I started the install.  Everything went by the book.  My list hadn't failed me......until I logged into OWA.  I was met with a sad face ...

You got yourself a shiny new Lync 2013 environment.  You navigated the namespace maze. You tamed the certificate beast. And you even managed to persuade the network guy to open up all those ports and create the reverse proxies. Users are logging in, chats are being had, and desktops are being shared.  All in all you feel good, and so you should.  Then, the calls start coming in.  Jim and Mary just looked at their outlook address books and they have thousands of duplicate contacts.  Has your shiny new productivity tool gone up in flames already? Or are these just the beginning drops of the flood of calls to come? Keeping the panic at bay, let's fix this little issue and make our users happy, productive, and quiet again. First off, to the cause.  Microsoft released a dodgy version of the Lync client at some point.  See KB2916650 .  You want to be running at least version 15.0.4517.1005 of the Lync 2013 client. Get yourself up to at least th...

You have just found the perfect script online to take care of that weird, overly complex thing your boss asked you to do.  You have combed through the code to make sure nothing dodgy is hidden in there and modified it to fit your environment.  You launch the PowerShell command shell and run the script only to be greeted with some lovely red lettering informing you that your script is not digitally signed. This is the PowerShell execution policy at work.  From a security stand point its fantastic.  It prevents people from running malicious scripts they find on the internet.  A security measure sorely lacking with VBScripts and batch files. From an IT admins standpoint it's a pain in the ass because it's standing between you and the completion of an annoying task that needs to go away so you can move onto the next project\fire\lunch. For those of you in a rush here is the quick and dirty way around this. Open PowerShell as an administrator (The old righ...