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.
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.
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.