Exploring Azure AD Connect - Establishing Synchronization with Express Configuration

Other posts in this series:

• Exploring Azure AD Connect - Part 2: Configuring SSO with AD FS
• Exploring Azure AD Connect - Part 3: Configuring User and Password Writeback with Azure AD Premium

Exploring Azure AD Connect - Part 1: Express Installation

Hello Unified Communications (and Office 365) enthusiasts! With the launch of General Availability for the new Azure AD Connect for Office 365 by Microsoft recently, I wanted to dig into this awesome new tool in a three-post series. For those that are not yet aware, AAD Connect is the latest version of what was DirSync, and the new features allow for a much more fluid and fully-connected hybrid environment. Check out this Office Mechanics segment to see what's new with Azure AD Connect:

This first post is going to focus on connecting an Office 365 environment with an On-Prem environment using the Express Installation. Before we dive straight in, let's take a second to talk about what our environment actually looks like.

Office 365 Environment

Rather than using a full-blown Office 365 suite, I am working with only Skype for Business Plan 2 licensing. To start with, I have a single admin user: admin@skype4businesslab.onmicrosoft.com. I have also added a test domain in called "s4blab.org", and setup all necessary DNS records through the Domain Add wizard within the Office 365 portal. Awesome!


On-Prem Lab Environment

My "On-Prem" environment is actually a virtual environment in Rackspace's Public Cloud. So far, the environment consists of:

• 1 Active Directory Domain Controller
• 1 Exchange Server (setup for later Demo of Exchange On-Prem to Skype for Business Online Hybrid configuration; stay tuned!)
• 1 small server for installing Azure Active Directory Connect

We will be expanding that a bit for ADFS in the other posts later in this series. So, let's get started with how to set this up!

Configuring Azure AD Connect: Express Installation

• First, get familiar with accessing your Azure AD. From within the Office 365 portal, on the left-side menu, navigate to: ADMIN -> Azure AD
  
• Once you have set up your profile for accessing Azure AD, you will see the below screen. As you can see, with Active Directory highlighted on the left, we can see that we have one directory currently setup, named "The MS UC Guy". This is the directory that was created with our Skype for Business Plan 2 subscription.
  
• Click on the name of your existing Azure Active Directory, Once you do this, you will see where you can manage your Users, Groups, Applications, Domains, Licenses, Reports, and Directory Integration! Click on Directory Integration, and you will see that Directory Sync is currently Deactivated, but that there are a series of steps to complete. First, since we have already added our "s4blab.org" domain, we go to Step 2, where we see we need to toggle the setting to "Activated". 
  
• Once this is done, We go to Step 3, where we are instructed to download the sync tool. DO NOT DO THIS from this area in the portal (at the time of this posting, anyway), as the sync tool available for download is not the new and improved Azure AD Connect. Instead, you can download the new tool from here: https://www.microsoft.com/en-us/download/details.aspx?id=47594
• Once you have downloaded Azure AD Connect onto the VM in your On-Prem lab, double-click it to get started. You will have to agree to the license terms, etc, on the first screen, and then you will see the below screen after clicking Continue: 
  
• After clicking on "Use express settings", you will briefly see the wizard install other required components before bringing you to the Connect to Azure AD screen. At this screen, you need to input credentials with Global Admin access to your Office 365 subscription. I would advise using credentials that are setup as such: admin@yourdomain.onmicrosoft.com, I tried using credentials from the domain that I was about to sync (@yourdomain.com), and I received an error about the account being in the same forest.
  
• The next screen is where you input your Domain Admin credentials for your On-Prem Active Directory environment. These creds will obviously be from the domain that you are attempting to sync to Office 365.
  
• Finally, you are presented with the Ready to configure screen. This screen reviews the actions that are about to be taken, allows you run the sync after installation is complete via a checkbox, and then lastly offers a checkbox for you to specify whether or not this is intended to be an Exchange Hybrid Deployment. This would be that I intended to have Exchange accounts both within Office 365, AND On-Prem. Since I do not intend to do that (remember, I only have Skype for Business Plan 2 licences at this point), I will leave it in the default un-checked state, and then click Install: 
  
• At this stage, several components get configured, and the screen updates you as it installs and configures each component: 
  
• Lastly, the wizard reports that configuration is complete, and it instructs you to log into Azure AD to check on the status of the synchronized accounts. You can now click Exit. 
  

At this stage, the Azure AD Connect wizard is complete, all required components have been installed on-prem, and we should now be able to go into Office 365 to check on the status of our Synced accounts. Below, while in USERS -> Active Users within the Office 365 portal, you can see a few users that I created in my On-Prem environment (marked by the orange arrows). These users also have a Status of Synced with Active Directory. Respectively, we have Captain Awesome (captain.awesome@s4blab.org), Josh B (josh@s4blab.org), and Princess Toadstool (princess.toadstool@s4blab.org). You will also notice a good handful of Exchange-related accounts that were synced, and finally the "On-Premises Directory Synchronization Service Account" that was created by this process. 

Also, if we go to our Azure AD portal, we can now see that our last sync was less than an hour ago, that Synchronization is Activated, and that we are good to go. 

It is important to note, at this point, that while we have synced our AD, we have NOT enabled Single Sign-On (SSO). We have simply made it so that our usernames and passwords that lived on-prem are now synced to Office 365. Those users can now be assigned Skype for Business licenses (or whatever other Office 365 licenses we might buy), and can log into a Skype for Business client using the same credentials that they log into their on-prem resources with, like an Exchange mailbox, or their desktop. 

Stay tuned for further exploration of the Azure AD Connect tool, including SSO capabilities, and it's awesome new Writeback features!

Stay techy, my friends!

Sway: Taking a Test Drive With One of Microsoft's Newest Collaboration Tools

A cool tool - but work to be done, still

Well, I made my first "Sway", and I have to say, I love this new method of whipping up presentations and sharing content, while having the option to collaborate with other authors on a project! Sway is very simple and easy to use, and the supply of working examples truly help to provide some inspiration about how to get started. Before I share mine, I just wanted to go over a few features that I think are truly awesome, and then highlight a few small areas that I think there is still work to be done.

Awesome Features

• Sway is 100% web-based, meaning it can be worked on and accessed from ANYWHERE.
• Content is easily searchable from within the web-based Sway editor, but access to private content is available through direct upload or OneDrive.
• Multiple ways to present content allows for fresh and evolving presentation, helping to keep the project from feeling boring or stagnant.
• It is extremely easy to share the presentation via multiple social channels, as well as through embedding or link sharing.

Areas for Improvement

• There are very few options for Font, and customizing Font and design colors (background, etc.)  in different parts of the presentation did not seem to be possible (unless I missed something)
• Font sizing didn't seem possible; I only observed a regular text size, and then the "Header" size, but nothing in-between.
• The ability to drag elements around within the Preview would be awesome! For instance, I would like to drag the Heading text around over the background image for optimal placement.
• The ability to videos within a "Stack" group, mixed in with pictures, would be really cool. 

Obviously Sway is still in "Preview", so I am sure many improvements and changes are coming. I am excited to see it in its current state, with its current set of capabilities, and I look forward to what is to come. Enjoy my Sway about the Awesomeness of Rackspace Hosting as a provider!

Stay techy, my friends!

Adding Personal Skype Contacts in Skype for Business

So, what's the deal with adding non-Microsoft Live ID contacts in S4B?

I figured the traditional sarcastic meme was the appropriate way to start this post, as I have seen a fair amount of back-and-forth around this topic in various forums. At the heart of this topic is the fact that  the ability to add personal Skype contacts, specfically Skype contacts that do not use a Microsoft Live ID to sign in, was touted as a cool new feature of the soon-to-be released Skype for Business Server 2015 earlier this year. This feature was highly anticipated by many Lync Server administrators.

While we all awaited the launch and availability of Skype for Business Server 2015, Skype for Business Online began getting rolled out, and there were many announcements and product updates highlighting this. This means that Skype for Business Online was the platform that early adopters had to use as their initial playground and testbed. That is all fine and good, except that there began to be confusion about the phased rollout of updating existing Lync Online users to be Skype for Business Online users. To compound the confusion, the Skype for Business user interface was released in an Office update before ANY of the server releases, and communication that clarified all this was a bit...sketchy. 

The end result of the above set of circumstances was that there were many users that thought that they were fully migrated to Skype for Business Online, and therefore had the full set of features available, when in reality this was not the case for such users. So, there were many people that expected to start being able to federate with personal Skype contacts. Instead, what many of them encountered was the same functionality as before: the Skype contacts had to be signed in with Microsoft Live-ID connected accounts. Articles like the following added confusions, because they reinforced this requirement: https://support.office.com/en-ca/article/What-to-try-if-you-cant-IM-Skype-for-Business-Lync-or-Skype-external-contacts-87f6d5d7-3b8c-4196-9c8c-1dabb75f54b8?ui=en-US&rs=en-CA&ad=CA. 

The Smoke Has Cleared, and the Skype Directory IS Available in S4B!

However, despite the confusion, the Skype Directory IS accessible, and personal Skype contacts CAN be added, provided that the backend Front End and Edge servers are both running Skype for Business Server 2015. There you have it: Skype for Business Online users that are fully migrated are now able to add personal Skype contacts, and on-premise environments with both Skype for Business Server 2015 Front Ends and Edge servers can do the same. For confirmation, check out the following links:

https://technet.microsoft.com/en-us/library/dn705313.aspx

http://community.office365.com/en-us/f/166/t/346441.aspx

Alright, well, this was not really an elaborate "How-To" or anything, but this seemed to be a topic I have seen resurface several times, each time without much clarity, so I wanted to help shed some light on it all. I hope this helps at least a few of you out there!

Stay techy, my friends!

Skype for Business Voice Route Ordering Per PSTN Usage

Does the order really matter?

So, we all know that Enterprise Voice can be a tricky thing to navigate in Skype for Business and Lync Server. This is especially true if there are multiple conferencing numbers in multiple regions, with multiple routes/trunks/voice polices/etc. The key word to here seems to be "multiple", wouldn't you say? If we only one had site, and only really needed to dial numbers within the US, and only had one conference number, then things would be SO much easier, right? The reality, though, is that many of us might feel like this when trying to get our Enterprise Voice routing just right:

So, with the assumption that we already know that PSTN Usages will be tried in the order in which they appear within a Voice Policy, and each PSTN Usage is then associated with a Voice Route, why do we need to be concerned with the order of Routes? Would that not be decided by by the order of the PSTN Usages within a given Voice Policy, as we just mentioned? Very good questions.

First of all, yes, the Route order would be determined by the PSTN Usage order that the Route is associated with within a Voice Policy. BUT, let's not forget about that beautiful M:N Routing functionality! Essentially, the above is true, but only under the assumption that there is only 1 Route associated with a given PSTN Usage. If we mix it up a bit, though, and have multiple Routes associate with a PSTN Usage (are your eyes crossing yet?), then how do we control the order in which the routes will be tried for a single PSTN Usage? And again, does it even matter, as long as the call gets where it needs to go?

The short answer is Yes, it can matter, though it often does not. Let's take a look at how we would even go about re-ordering the routes in the Skype for Business Control Panel, and then answer why this may matter.

How to order Routes for a single PSTN Usage

Alright, so first, let's take a look at a Voice Policy in our Skype for Business Control Panel. Here we see that we have a single policy, the default 'Global' policy. Just from this screenshot, we can already see that there are two PSTN Usages assigned to this policy: "Local", and "Long Distance".

Now, when we open up our 'Global' voice policy, we have a bit more information. For our purposes, we are going to be focusing on the PSTN Usage called "Long Distance". Looking at the Associated routes of the "Long Distance" usage, we can see that there are two routes associated already: "Long-Distance-Belgium" and "Long-Distance-UK-Route". Obviously the first route is intended to route calls to a trunk for Belgium-bound calls, and the second is for calls that are destined for the UK.

The order that the Associated routes appear in in the above screen is the order in which the routes will be tried (again, we will go over why it might matter which ones are tried first shortly). For argument's sake, let's say we want to try the UK route before the Belgium route. Obviously, we need to change the current order. If we highlight the "Long Distance" PSTN Usage and click on Show details, we are presented with the below screen:  

As you can see from the navigation menu at the top, we are viewing each of the routes associated with a PSTN Usage within the Voice Policy itself. We can also see that the only option here is to rename the PSTN Usage; we can view the details of the routes, and add new routes to be associated with the PSTN Usage, but there is no way to re-order the routes in the above screen. This is true even when we navigate to the PSTN USages tab and click on the specific Usage's settings, because if we recall, PSTN Usages have no settings themselves; they can be named, and then associated with voice policies and routes, but that is it.

So, if we can't modify the order that the routes are tried in for a given PSTN Usage from the voice policy or the PSTN Usage itself, where can we modify the order? Well, it may seem a little backward at first, but the Routes tab is actually where you would go to do this. As you can see below, each route is listed, and when one route is highlighted, the menu above the routes gives you options to either move that route up, or down. Notice that the order of the routes below (from top to bottom) is the same order as how the routes appear when looking at the PSTN Usage settings within the 'Global' voice policy.

So, as our goal is to have the UK route tried first for a match with the already normalized number being dialed, we want to:

1. Highlight the "Long-Distance-UK-Route" route
2. Click on the Move up menu item
3. Click the Commit drop down, and select Commit All
4. Click OK when prompted
5. Rejoice because you just changed the route order!

Note: in a production environment, you may want to triple check your work, and run a couple test scenarios before "Committing" the changes. Check out the order now:

To double check our work and make sure that order of the routes has been changed for the PSTN Usage, let's go back and look at the PSTN Usage in our 'Global' voice policy:

Sure enough! The routes are now re-ordered, and any call that gets dialed and tried through the "Long Distance" PSTN Usage will try the UK route for a match first.

So, why would you care about the route order?

As for why the route order matters, for the most part, especially in smaller, less complicated environments, the order does not really matter. However, in the event that you have more than one route associate with a PSTN Usage, and more than one of the routes would be a match for the normalized number, but each route would send the call to a different destination, your calls may not be sent to the destination that you are hoping for. So it may be important to re-order the more specific routes to the top, and leave the routes that are more "catch-all" in nature toward the bottom.

Another reason that you may want to re-order your routes for a single PSTN Usage would be to optimize traffic in your environment. For example, given the above scenario, let's say that you have a LOT of voice traffic, and your servers are hit pretty hard with processing those dialed numbers. Now let's say that almost all of your international calls are to the UK. If you had not changed your order above, then the server has to try the Belgium route first for each international call, putting more strain on the server. Once the re-order was committed, most of those calls are only going to have to try one route now, as opposed to two, before being successfully routed.

Well, once again, I hope this has been helpful Thanks for sticking through my commentary to get to the meat of this topic, and feel free to share your thoughts!

Stay techy, my friends!

Skype for Business Install on Windows Server 2012 R2: Don't forget KB2982006

Hello all! It's been a busy start to the week, but I wanted to take a quick moment to share a tidbit of knowledge I have run acrosse while installing Skype for Business. Here is the scenario:

• Setting up a small lab with Rackspace Public Cloud VMs.
• Deploying a Standard Edition install of Skype for Business
• Server OS is Windows Server 2012 R2
• Server has been added to AD Domain
• All Windows & Security updates have been installed
• All Prerequisite Roles & Features have been installed
• Administrative Tools were installed
• AD  was prepared by extending Schema, preparing Forest, and preparing Domain
• Prepare First Standard Edition Server step was successfully run
• On the Install or Update Skype for Business Server System step, Step 1 completed successfully

Then, the problem: Step 2 failed with the error stating that not all prerequisites had been met, and it cites the KB article 2982006. This update was not picked up my the local OS when checking for updates, apparently, but is required by Skype for Business Server for install.

Now, to obtain the update, you can start the download process by clicking on the "Hotfix  Download Available" button here: https://support.microsoft.com/en-us/kb/2982006. Once you do this, though, it is not a direct download. You are prompted to first select the proper download, which should be the x64 version of the download, and then you must enter your email address. Within a few minutes, you should receive an email from Microsoft with a link for a direct download of the hotfix. This email also includes a whole lot of warnings about backing up your environment and disclaimer-like information. In my case, this is for a basic lab, so I pretty much ignored all the fine print, and just installed the hotfix. It DID NOT require a reboot.

Once you have installed the hotfix, you should be able to re-run Step 2 successfully, and on you go to Skype for Business Server 2015 testing and fun!  For any of you getting briefly stuck on this, or just planning for your environment in advance, please simply take note that KB2982006 is a prerequisite that does not get downloaded in the normal updates.

Thanks for reading!

Stay techy, my friends!

Tools of the Trade - Office 365 Tools for Hybrid Deployments and Migrations - Part 3

Other articles in this series:

• Tools of the Trade - Office 365 Tools for Hybrid Deployments and Migrations - Part 1
• Tools of the Trade - Office 365 Tools for Hybrid Deployments and Migrations - Part 2

Office 365 Tools Recap

In the two previous posts in this series, we took a look at some tools that are used in the planning and deployment phases of an Office 365 hybrid implemenation or migration.  We explored a couple of the tools used for evaluating your environment's  preparedness for directory synchronization in the first post. Then we devoted the entire second post to the Microsoft Azure Active Directory Sync tool. Now we will wrap up this 3-part series with a look a few helpful tools for diagnosing and troubleshooting connectivity issues after an Office 365 deployment.

Intro to the Tools

There are plenty of tools out there, many by  Microsoft, for troubleshooting environments, and many could be used for troubleshooting connectivity with an Office 365 or hybrid environment. However, in this post we will focus on three tools that will be most helpful for ensuring our public facing configuration is setup properly: the Microsoft Remote Connectivity Analyzer (MRCA), the Microsoft Connectivity Analyzer (MCA), and the Microsoft Lync Connectivity Analyzer.

I felt the above image was appropriate for two reasons. First, Nick Burns is freakin' hilarious. If you have never seen an SNL Nick Burns skit, let me do you a  favor:

The second reason that I felt the above meme was appropriate was because Microsoft sure didn't do us any favors with how similarly these tools are named! Especially when it comes time to take the certification exams, trying to remember which functions matched to which tool when they all sound very similar can be a bit challenging. At any  rate, I have digressed quite a bit, so lets move on to the Microsoft Remote Connectivity Analyzer.

Microsoft Remote Connectivity Analyzer

This tool is simply awesome, and has the capability to help troubleshoot, diagnose, and verify settings for various public-facing applications. For example, it can conduct analsis on Office 365 setups, on-prem Lync and OCS environments, and on-prem Exchange environments, among others. The tool is a website, making it reachable from anywhere, and not at all burdensome to your local device. It can be reached at: https://testconnectivity.microsoft.com.

Once you have arrived at the landing page for the tool, you will immediately notice the availability to test the various server components via the tabbed structure, simplifying navigation. The various tests will help you verify things like your required public DNS records, whether or not SSL certificates check out as they should, and whether or not the servers are responding on the expected ports. They can also test autodiscover settings, and verify credentials for remote access. 

Obviously the best way to get familiar with the individual tests and analysis options is to visit the site and look around on each tab. To get even more familiar with the tool, try feeding it some values for tests that are relevant to your own environment, and explore the output.

Microsoft Connectivity Analyzer

See what I mean about the tools being named similarly? At any rate, this tool is called out as a companion to the MRCA tool, but unlike the MRCA, it is a tool that must be downloaded locally; it is not a web interface. To run this tool, your client must be running Windows Vista or newer, and if running it on a server, the server needs to be running Windows Server 2008 or newer. In each case, the .NET Framework 4.5 is required.

The Microsoft Connectivity Analyzer can be used by administrators and end users, alike. Its main purpose is to test connectivity between email clients and servers running Exchange server. This is where I must stop and ask, why couldn't this tool have been names something like "Exchange Connectivity Analyzer" or "Microsoft Email Client Connectivity Analyzer"? Honestly, wouldn't either of these have been more descriptive and less confusing for the overall collection of tools? I digress....The tool is simply meant to simulate various client logon and mail flow scenarios, and would therefore be a useful tool for related situations in which there is doubt about a client's logon ability, or what mail flow pattern is being experienced.

Microsoft Lync Connectivity Analyzer

This last tool, as you can see WAS named a in a little more descriptive manner. This tool has a very specific purpose. It is meant to determine if a Lync environment, either on-prem or Skype for Business Online, meets the necessary requirements for client connectivity from mobile clients and the Lync Windows Store App. While the name of the tool would almost indicate that the tool was used for testing all connectivity to a Lync environment, it is in fact only used for the tests I just mentioned.

The tool, in the course of its analysis, tests several components. Among them, it checks public DNS records to make sure the  necessary A records and SRV records are in place. It also checks the proxy configuration for the environment. Lastly, but definitely not least important, it checks on the validity of the SSL certificates that are in place.

Wrapping it up...

Well, that about does it for our review of a great set of tools for preparing for,  deploying, and troubleshooting Office 365. I hope you all have found this information helpful, and hopefully it will come in handy while you are transitioning your company to the awesomeness that is Office 365. 

Stay techy, my friends!

Tools of the Trade - Office 365 Tools for Hybrid Deployments and Migrations - Part 2

Other articles in this series:

• Tools of the Trade - Office 365 Tools for Hybrid Deployments and Migrations - Part 1

What is the "DirSync" Tool?

DirSync is the easire-to-say name for the Microsoft Azure Active Diretory Sync tool. And honestly, with a name that long, a much-abbreviated form was definitely needed for a tool that would be at the center of almost all Hybrid environments with Office 365. So, what is it used for? Quite simply, it is the tool that is used to synchronize your Active Directory users in your On-Prem environment to your Office 365 deployment. You can use it to sync all users, or you can apply filters and synchronize only certain groups, depending on your plans for Office 365 usage.

Why is this important?  I will answer that by also answering why it is AWESOME. Let's say your plan is to house your Lync deployment on-prem (or Skype for Business deployment because you are cool and stay up with the times), but you want to migrate your Exchange users to Exchange Online. Ok, so now you need to create all those users in Office 365, so that they can access Exchange Online. Wait, does this mean that they have to sign in to Lync using one set of credentials, and Exchange Online with another set of credentials? Well, yes, it would mean that, if you didn't synchronize all of your existing users from your on-prem Active Directory. By putting this synchronization into place, all your users will stay properly synced up to Office 365, and you can even manage their accounts and settings from your on-prem environment, with the changes being synced to the account in the cloud. And this means that SSO can also be achieved! Oh happy day!!

What are the requirements for DirSync?

First of all, this tool should only be downloaded onto, and running from, a single machine in your domain. Further more, this server is not recommended to be a Domain Controller, as issues can arise (see my previous article about a specific issue that you will encounter: http://blog.msucguy.com/2015/04/office-365-directory-synchronization.html). It doesn't mean that it won't work on a DC, but if we are talking about a production environment, I would stick to the recommended guidelines.

Secondly, you will need to deploy Active Directory Federation Services in your environment if you wish to achieve Single-Sign On (SSO) functionality. This is very important for companies that want a streamlined user experience - not wanting users to feel like they are in two different environments, but rather working out of the same single environment like they normally would. This article does a great job explaining where ADFS comes into play, and the other types of synchronizations that can be used with it: https://support.office.com/en-ca/article/Understanding-Office-365-identity-and-Azure-Active-Directory-06a189e7-5ec6-4af2-94bf-a22ea225a7a9.

Ok, what about the Technical requirements?

Alright, to get to the nitty-gritty, here is a list of system and envirnment requirements that are more technically specific:

• The server used for the DirSync tool must be running one of the following operating systems:
• Windows Server 2008 R2 w/ SP1, x64 (Standard, Enterprise, or Datacenter)
• Windows Server 2012 (Standar or Datacenter Editions)
• Windows Server 2012 R2 (Standard or Datacenter Editions)
• The server must be joined to the Active Directory domain that is being synchronized
• The AD Forest Functional level must be at least Windows Server 2003
• The server must have Powershell installed (and enabled, if relevant)
• The server requires both .NET Framework 3.5 SP1 and .NET Framework 4.5.1
• The Domain Controllers in the environment must be running one of the following operating systems:
• Windows Server 2003 SP1 (32 or 64-bit)
• Windows Server 2008 (32 or 64-bit) (Standard or Enterprise Editions)
• Windows Server 2008 R2 (Standard or Enterprise Editions)
• Windows Server 2008 Datacenter Edition
• Windows Server 2008 R2 Datacenter Edition
• Windows Server 2012 (Standard or Datacenter Editions)

While the above information may seem drab, and may not pertain to too many newer environments, it can be very good information to know if you are planning on taking the Office 365 certification exams. Just sayin'...

There are other articles out there that go into much deeper dives on this tool, and I would of course encourage you to dig into them if you are moving past this introductory phase and getting ready to do so serious DirSync management. I would especially encourage you to get very familiar with the Powershell tools and cmdlets that are available for directory synchronization and remote Office 365 management, as provisioning automation will definitely rely on a solid understanding of Powershell.

For an overview on the various tools that can be used after your Hybrid deployment (or in-between phases of the deployment), check back with me on the third and final post of this series. We will be going down the list of some great connectivity testing and troubleshooting tools.

I would also like to apologize for the lack of a borderline-sarcastic meme in this post. I shall strive to not let that happen again!

Stay techy, my friends.