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.

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

Other posts in this series:

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

An Introduction to the Tools of the Trade Series

Who wants to diagnose car troubles without any tools? Better yet, who wants to build a car without any tools? Not normal people, I can tell you that much! As much as I don't really consider myself to be a normal person, I do fall into the category of persons that would prefer to have the proper tools to do a job, especially if that job is to setup a hybrid deployment between an Office 365 enviroment and an On-Prem environment (or to troubleshoot ensuing integration problems).

Microsoft has a knack for building various tool sets around its products, and Office 365 and associated UC applications are no exception to that rule. As a matter of fact, this abundance of tools can start to get a little confusing, as some of the names are very similar, and functionality even seems to overlap a bit in some of the tools. 

This 3-part series will focus on tools for all aspects of an Office 365 Hybrid deployment or migration. The first post will focus on tools used for preparing your on-premises environment for integration with Office 365. The second post will be devoted completely to the Microsoft Azure Active Directory Sync Tool (DirSync). Finally, we will wrap up with the various tools that can be used to test different connectivity scenarios, and to troubleshoot issues that arise post-deployment.

Preparing for Office 365 Hybrid Deployments or Migrations

Did you ever invest a huge amount of time into completing a task, only to find out right as you were finishing that you could have done it in a fraction of the time, with a much simpler procedure? I think most of us have been there. This guy has for sure:

Sometimes it pays to use the right tools, or methodologies, from the beginning! A good starting point, though, is to know what those tools are. So, for all you Admins/Engineers out there that are getting ready to dive into Office 365 for your environment, especially if you are planning a hybrid environment or a complete migration, here are a couple tools that I think you will find incredibly useful at the beginning of your journey.

Office 365 Readiness Checks

Microsoft did us a solid by placing many of the tools that we would want right in the Office 365 Admin Center. The Office 365 Readiness Checks are a great set of checks that are installed and run from our client PC/laptop. To get to these tools, you will need to be logged into the Office 365 Admin Center, and then you can browse here: https://portal.microsoftonline.com/tools. You can then click on the top link titled, Check your Office 365 configuration with Office 365 health, readiness, and connectivity checks (By the way, you will also notice that there are other tools in this section of the portal that we will discuss in a post later in the series).

You will then be guided through the process of conducting these checks. These checks are great to run before your deployment, before launching new services in a deployment, and between each phase of a phased deployment. Your system requirements are fairly easy to meet: you need to have a client OS that is at least Windows 7 (64-bit), and .NET Framework 3.5 needs to be installed. Keep in mind that these checks will be investigating different aspects of your environment, as well as your Office setup, and diagnosing its readiness for integration with Office 365. This means that you will want to be running these checks using an account that has admin-level permissions within the environment.

IdFix DirSync Remediation Tool

Next up on the list, and the only other tool I am discussing concerning preparation for Office 365 integration, is the IdFix DirSync Remediation Tool. The name almost kind of reminds you of Microsoft's Fixit tool, doesn't it? At any rate, this tool is very important for saving you time that you may be spending trying to remediate errors that you could potentially run into when running the DirSync tool (discussed in the next post in this series).

This tool is a download, and it requires at least Windows Server 2008 R2 on the server side, or Windows 7 (64-bit) on the client-side. It's purpose is to ensure that your Active Directory environment is in a ready state for running directory synchronization to Office 365. The tool does a discovery within your AD environment, and then identifies areas of remediation that are required before you attempt to run the DirSync tool. This could potentially save you a bunch of time trying to track down the root cause of errors that you would face in the DirSync tool.

Let's consider the example of a company that has an on-prem Exchange and Lync setup, and uses the public domain 'contoso.org' for their email addresses. They they go and setup Office 365 with a domain called 'contoso.com', and they are using that domain for Exchange Online and Lync Online (excuse me, Skype for Business Online). When they attempt to run the DirSync tool between environments, they are going to run into errors because of the domain mismatch. This is where the IdFix tool can save them the headache, by identifying the incompatibilities ahead of time, and pointing the admin/engineer in the right direction to get the on-prem environment properly prepared.

Conclusion

Well, that wraps it up for this post. While there are other tools out there that may assist in the preparation phase of a deployment, these two should get you started by ensuring that your environment is well prepared and compatible with your Office 365 environment. In our next post, we will dig into the DirSync tool a bit, going over some of the system and environment requirements for running the tool, and discussing a few key points about it. We will conclude the series after our discussion on DirSync by going over the various tools that can help in testing and troubleshooting client connectivity scenarios.

Stay Techy, my friends!