It’s been a touch over five years now since I started down the path of documenting Lync (now Skype for Business) via PowerShell scripting, my original “Making sense of a TBXML” post went up on September 11, 2011. I remember publishing the big update to it in February of 2013 in San Diego at the first Lync Conference. Since then, the script and it’s updated versions have been downloaded over 8,200 times since I last checked. I’m dreadful at being consistent with updates; unfortunately, I will fix bugs that I find but have a habit of not pushing those updates publically regularly.
With all of that being said, I have finally gotten around to my latest update, or I guess I should say iteration as it has been about a 95% ground up rewrite. For that reason, I am not updating the original script version or post but instead publishing this as a new version.
- The largest change is to the structure and formatting of the Visio diagram. The previous version used an isometric layout that I spent weeks if not months trying to perfect, only for Microsoft to come along and update the stencils and change the style to the flat Metro UI style.
- I’ve reworked the Visio diagram to show the firewall traffic ports required for Edge services within the environment; this has been a big request for some time now. It is not 100% complete as I have not implemented the reverse proxy traffic flows entirely, so I have some work for the next update.
- An example of the Visio diagram is displayed below. I am open to comments, criticism, and suggestions so please feel free to share your thoughts.
- The Excel workbook containing the voice documentation and configuration is mostly unchanged apart from better data parsing on the backend and some cosmetic changes for presentation.
- The Word report includes additional information for things like Database Mirroring state, Topology Replication details, Windows Hotfix install details, and a few other new items. I have tried to format the tables in the document better to ensure a cleaner more legible design, but it still may require some manual correction depending on the complexity of the environment.
- Finally the data collection script itself. I have completely re-done the data collection script to store and sort the information more efficiently. The result is that in my lab, where the previous version of the script generated an XML file that was about 11MB uncompressed, the XML from the new version clocks in at 38MB uncompressed. Don’t worry; it’s still compressed for storage and transfer in a ZIP archive resulting in the file compressing from 38MB down to just 910KB.
- Before everyone asks, no the data files generated from the old version will not work with this version and vice-versa. I wanted to make it compatible but ultimately it was just too much work for too little benefit.
Download HERE on the TechNet Gallery.
One of the most requested features for the Lync Environment Report package has always been support for custom Word document templates. I wrote the capability to support it sometime early last year but never got around to making it available publicly. Pat Richard from ehloworld.com asked me about it today, so I packaged it up and now it’s here.
I’ve added a -Template option to the New-LyncEnvReport.ps1 script that accepts the path to a Word document to be used as a template. You will need to open the script and tweak a couple things to make it work with your template though. There is a new section near the top of the script where you can configure the style names for the Section headers and table styles you want to use.
The other big change I made was to remove the auto download option for the Visio stencils from Microsoft’s website. It was still configured to look for the older version which is no longer available. I have updated the script to check the “My Documents\My Shapes” folder for the 2012_Stencil_121412.vss file which is available for download here: http://www.microsoft.com/en-us/download/details.aspx?id=35772
You can download the latest update on the TechNet Gallery here: https://gallery.technet.microsoft.com/Lync-Environment-Report-cbc6fb1a
If you find any errors or encounter any problems, shoot me an email or leave a comment for me.
It’s been a year and a half since I last posted and a while a lot has changed plenty still remains the same. I found myself thinking today of the old cliche adage “If I have seen further it is by standing on the shoulders of giants.” I greatly appreciate the work of those that came before me and shared their knowledge freely; be it in person, online, or via a blog posting. I have learned so much from others but I feel like I haven’t done much to give back lately to the wider community, so I’d like to change that. I’ve amassed a collection of scripts, utilities, and even just code snippets over the past couple years and I am working to get them cleaned up and published. All will be released under the Creative Commons license free for personal use with attribution.
I’m all about automating documentation, you might think it’s because I like writing documentation. Nope, like most others I loathe having to gather a produce documentation but I recognize it’s value and the reasoning for it. And I’ve been saved by it more than once.
That being said if I can automate it I will find a way. Having previously produced my Lync environment documentation scripts, I found I was missing information on a crucial Lync component; the Lync voice gateway. I primarily encounter a lot of AudioCodes gateways and they’re the ones I have the most experience with, so I chose to start with them.
I’m not opposed to expanding this to include Sonus, AcmePacket, or any of the other guys out there. I just don’t have any hardware or config files from those guys to use as reference.
It’s been about 573 days or almost 75 weeks since I originally published my blog post titled “Making sense of a TBXML” which included a PowerShell script that could parse the data from a Lync Topology Builder file and create a spreadsheet and Visio diagram. I’ve published a few blog posts since then with new scripts, but never stopped working on improving my Lync Documentation Script. It has grown immeasurably in complexity and capability since then.
Before I get into all the gory details, I’d like to thank a few people for their help along the way. Thank you to Pat Richard and Luke Kannel who helped test out the earlier versions and provided invaluable feedback on bugs, fixes, and features. I’d also like to thank the guys over at DigiCert for their help in getting me a code signing certificate so all of these scripts could be signed. And last but certainly not least a giant thank you to Tim Harrington who spent a stupid amount of hours testing, validating, and providing great feedback.
I’ve spent a decent chunk of time setting up my VM test lab, as I’m sure many others have. In my lab I have AD, Exchange 2010, Lync 2010 & 2013, TMG, an Asterisk based PBX, and a couple client VMs running Windows 7 with Office and the Lync client installed. It’s a great learning exercise to get everything setup and be able to play around with the configuration options. I’ve actually lost count at how many times I’ve wiped and rebuilt my lab to test different scenarios. I like to simplify the setup as much as possible to reduce the time needed for setup.
One necessity I’ve run into with my lab is test user accounts. Originally like a lot of other people out there I started with just a few accounts with names like TestUser1 or Exch2010UserB. Don’t get me wrong, it works just fine for testing; but I wanted more. So what started with me generating a list of 50 random names, to name my test user accounts, eventually grew into what I’m posting today. Read further to learn about New-AdTestUsers.
The Archiving server role in Lync 2010 does a pretty decent job of living up to it’s namesake in archiving messaging data. Whether on a SAN or locally attached, disk space is not infinite. This means we can’t keep data in SQL forever, even if we need to keep the data around. One option natively built into the Lync PowerShell Cmdlets is Export-CSArchivingData which does exactly what it says and exports archiving data to EML format for backup or viewing. My problem is that this is a manual process and needs human intervention and/or interaction. To fix this, I did what I tend to do best and automated it via PowerShell.
Microsoft’s recommended order for deployment when moving from OCS to Lync is to migrate you’re internal services (Front-End pools, mediation, archiving, etc) first, and then to migrate your Edge services to the new Lync servers last. As I found out, there’s a good reason for the order they suggest. With Lync came the ability to create external access policies, which among other things control who can login remotely. Funny thing though, OCS clients don’t respect these policies because they don’t know anything about them. And even if Microsoft created an update for the client OCS to enable it to use Lync policies, you would still be able to get around it by using a non-updated version of the OCS client.
Now, I hear what you’re saying, “Isn’t this why Microsoft created the ‘Client Version Filter’ in Lync to control this behavior?” Yes, but what about during the migration process where you may still have users on the OCS client? That’s why Microsoft recommends moving Edge services last. But sometimes this isn’t always possible, especially if there were no OCS Edge servers within the existing deployment. This is where I found myself last week. No way to block OCS clients from connecting externally without interfering with internal OCS users during the migration process. After some Googling I came across a blog post from Mark King over at UnplugThePBX which explains the whole scenario and can be found here http://tinyurl.com/em2501
Checkout my solution after the break.