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.
I recently had someone ask me about call forwarding and simultaneous ring configuration within Skype for Business server. Specifically, they were trying to understand where the data is actually stored within the environment. I did some quick googling through which I found references to SefaUtil and a couple people who have written some fantastic GUI wrappers for it, but not much in terms of where the data is actually stored. I did manage to find one script that pulled the information from data extracted via the Export-CsUserData cmdlet, which ultimately pointed me in the right direction.
So the short answer is that the data is stored in the RTCLOCAL SQL Express instance on the user’s primary home server in the “PublishedStaticInstance” table. To get the information I wrote a script that takes the user’s SIP Address, looks up their primary home server, and then connects to the SQL Express instance to query for the data. Using the SIP Address you have to first query the “Resource” table to find the user’s ResourceId as that is what the information is stored under in the “PublishedStaticInstance” table. There is actually quite a bit of information in the “PublishedStaticInstance” table including details for blocked users amongst other things. But what we’re looking for is stored with a “CategoryId” of 8 which is routing information.
Parsing through the information returned you can see if the user has call forwarding and/or simultaneous ringing configured and if so what the destination SIP Address(es) or telephone numbers are. The “Client Flag” setting shows if the user has configured call forward or simultaneous ring, and the destinations will show below that. I’ve also included a -ShowXml parameter in the script that will display the full routing configuration just as it’s stored in SQL for reference.
As with everything I post, this script is for informational purposes only with no warranty or guarantee expressed, implied, or suggested. Feel free to let me know if you have any questions or comments.
Download on TechNet Gallery
It’s been over a year again since I last posted an update. My bad. Hopefully, today makes up for it.
I’ve got quite a few tools in my toolkit that I have developed over the years designing and building Lync and now Skype for Business deployments. Some of those are things like the documentation script I developed while others are people way smarter than myself willing to answer oddball questions. One of those people is Tim Harrington, who has spent a ton of time working with me on developing, debugging, and tuning this whole thing.
Alright enough of that, let’s get down it. Most anyone that knows me knows that I love automating things, oddly enough it seems I’ve started at the end of the deployment and worked backward. First was the as-built documentation script, followed by the install and deployment bits (not yet publicly released), and then finally actually was the design and planning phase.
I have added a couple updates for the environment report scripts. It wasn’t properly handling single Standard Edition servers when collecting certificate and software version information. I also added a step to parse the software version information for the new Skype for Business 2015 bits and corrected a couple typos. The updated files are available on the TechNet Gallery at the link below.
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.
I initially released the Lync Environment Report scripts back in February, and it’s been a whirlwind trip since them. I’ve been on the road for almost every week travelling since then. I’ve been trying to find time to work on finalizing a reporting script for AudioCodes voice gateway configuration files, and also get out responses and updates to the Lync Report scripts.
It’s been a slow and steady process but I’ve managed to package up an smallish update, with a promise that there is more to come. For now the biggest update is the addition of a new script, New-LyncEnvWorkBook.ps1, which exports the voice configuration to an Excel spreadsheet as shown below.
Lync voice configuration can be tricky and can have a lot policies, routes, and usages to consider. When presented in the Word tables, it very easily becomes cluttered and unreadable, so the logical choice was to move them to a better presentation format.
The other changes under the hood include-
- Correcting a few spelling mistakes.
- Setting all document generation scripts to temporarily use the “en-US” culture to account for localization problems with Office.
- Removing the THEMEVAL theme color reference in Visio as they seemed to cause most of the problems.
The updated package of scripts can still be found in the TechNet gallery for download at the address below.
One last thing, I am working on an online version of the report generation tools, that will greatly simplify the process and should be much quicker. It’s still a work in progress, but initial testing looks good. If you continue to have issues with report creation, let me know and I might be able to point towards the page for some testing.
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.