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.
One of the things that intrigued me the most when I first started working with Lync was the Topology Builder and it’s TBXML files. Whenever I walk into a new Lync environment one of the first things I do is to open the Lync Topology Builder and pull up the existing topology to get an idea of the deployment environment, it’s configuration, and any servers present within it. I’ve always heard from the people I talked to that the TBXML files were not readable or usable without the Topology Builder because they just didn’t make sense for anyone trying to look at them.
If you open a TBXML file within a text editor you’ll notice pretty quickly that its just like most other standard XML documents, a little hard to read but it contains a great deal of information if you know what you’re looking for. This got me started on developing a way to parse this information into a usable format. I started this thinking I would be done in a couple weeks tops, and yet here I sit almost six months later hoping that whats I’m posting is ready for prime-time. Originally I wanted to be able to parse all of the topology information into a Visio Diagram, but I just couldn’t get all the information in without making it cluttered. So I chose a different route, what if I could parse the TBXML data and then output a Visio VSD for a graphical representation of the topology and then layout the rest of the information into an Excel spreadsheet that contained all the details? I started building the solution as two different scripts, but it didn’t make sense to do duplicate work so I combined them.
Enter Get-LyncTopologyInfo! Below you’ll find all the information needed to run it and a copy of the script for download.
Haven’t been able to get any updates posted for a little while now, been busy with that whole day job thing. I know promised more Lync tools, they’re coming and soon I hope. If I can scratch out the time to put the finishing touches on them and do the finalized testing; I’d like to get the Topology Documenter and Topology Mapper posted by this weekend. I’ve had other things on my plate and figure it might make an interesting post. So… onto other things.
Officially, there is no Microsoft supported migration from Exchange 5.5 to Exchange 2010. The oldest supported environment you can upgrade to Exchange 2010 is Exchange 2003. So that normally leaves you with a two step method, 5.5 to 2003 and then 2003 to 2010. And if you’re lucky, Exchange 5.5 will be running on Server 2000 so you at least get Active Directory to make the process easier. No such luck for me. Mine was Exchange 5.5 on NT 4.0 to Exchange 2010 SP1 on Server 2008 R2 SP1. I know what you’re thinking, “Sounds like fun!” Luckily we were moving from one NT domain, OldDom, to another 2003 AD domain, NewDom, so that made it a little easier.
- Export your VCFG from the Lync Control Panel.
- Place the VCFG in the same folder as the LyncVCFGConverter.ps1 file.
- Open the Powershell Command Windows and navigate to the directory where you have the files stored.
- The syntax for running the script is .\LyncVCFGConverter.ps1 ConfigFileName.VCFG
- The script will automatically start processing the VCFG file and extract the data from it.
- Upon completion it will save the Excel spreadsheet and open it.
- The information is separated into the following tabs: Location Profiles, PSTN Usages, PSTN Routes, Voice Policies, and Trunk Configuration
It’s a pretty simple straight forward process, and it includes status updates along the way. I will get some screen shots posted with more information later today.