Using GAM to extract tenant data for a Google Apps to Office 365 migration

Google to Office 365 migrations are fairly complex for several reasons:

1. While coexistence is possible, it is difficult to configure and more difficult to communicate to your users effectively.
2. The end user experience is vastly unique, so communication plans need to be robust
3. Because a cutover migration tends to be more effective, it requires a lot of forethought to discover and recognize the gaps in process or behavior and determine which you can fix with a technical resolution and which need to be addressed in end user communication as a change.

One of the biggest uphill battles is extracting data from Google.  Granted Administrative rights in a Google tenant, there are not any export or save as options really presented to you.

Enter GAM (Google Account Manager)  Wiki here - GAM is a command line tool that allows administrators to manage many aspects of their Google Apps account

GAM can be used to report/export/document a google apps tenants:

• Users
• Groups
• Aliases
• Resource Calendars

The install and permissions model is well documented in the links above, be sure to use the latest version of GAM, they seem to consistently update it to include new functionality.

Once you have it installed and connected to the tenant there are several command you can use to extract data to a CSV file which can be users to script and create AD objects, cloud mailboxes, groups, resource mailboxes, etc.

Export users:

gam print users allfields > users.csv

Export groups:

Gam print groups gam print groups name description members managers owners settings > groups.csv

Export aliases:

gam print aliases allfields > aliases.csv

Export Resource calendars:

Gam print resources allfields > resources.csv

Of course, this is not a read only tool - you can also use the tool to edit/modify users in bulk.  For example, using a migration tool like BitTitan's MIgrationWiz, you are not able to extract data from a user who is disabled, so we can disable and enable users in the Google apps tenant using

Enable:

gam update user chrislehr suspended off

Disable:

gam update user chrislehr suspended on

Hope this helps, if there is more interest, I can show how I develop these CSV's into PowerShell to create everything in the Office 365 tenant!

Manipulating LogParser Data in Excel to prepare for Office 365

In a post I made back about a year ago, I posted about how to collect RPC logs to determine Outlook versions your organization is using.

It's been a pretty popular article, but I kind of didn't document the Excel part so I am circling back today to strengthen this aspect of the How-to.

So, starting with the CSV in that article:

1. Open the CSV in Excel
2. Hit Ctrl-A and select "format as a table" - you can choose to design if you want  :)
3. Then, on the table design tab, select "Summarize with Pivot Table"
   
4. Then, design your pivot table.  In this example, I will drag "Version" to both the rows and the values fields as shown to the right
5.  Once you have the pivot table, you can color code based on O365 compatibility (Office 2010 support ends in October 2015!)
6.  Now, you can review versions and choose if you want to drill into them by user and IP address!
   

  

O365 - Unknown Error adding a vanity domain

Problem:

Adding a domain in Office 365 Web UI, you add a domain name, get the verification DNS record created, click on verify and you get an "Unknown error"  You receive the same if you use Confirm-MSOLdomain.   If you use the Web UI, you will have the added pain factor that every time you attempt a verification, the DNS entry will change on you.  Especially frustrating if you are not the person in control of DNS and you repeat this process a few times before realizing the issue.

Analysis:

Obviously, something as generic as "Unknown Error" we cannot possibly state the root cause is going to be the same every single time.  Your mileage may vary here, but this is what we found, and if you can ask the right questions, you may be able to resolve this without contacting support.

For us, the root cause was that the vanity domain was already verified in another tenant.   That tenant had since been abandoned and none of the Global Admins were known.  I was able to call PSS, and they confirmed that this was indeed the case.  The next time I run into this, I will challenge the domain owner more to see if they know if they had a previous tenant they attempted and abandoned.

My Request:

This seems like something simple enough to make a friendly error like "this domain is in use, see here for instructions on gaining access to the domain"

If you want, you can even link here if getting a new KB together is difficult.  :)

Solution:

Follow the below steps for removing the domain from other tenant and adding it to your tenant.

In order to remove your domain from another Office 365 account, and to add your domain under your new tenant, follow these instructions:

1. Go to this link: http://www.powerbi.com/dashboards?WT.mc_id=PowerBI_com and enter a valid e-mail address associated with the domain suffix "company.com".
2. You will receive an e-mail and Follow the link in the email.
3. Generate a new password so that you can login into company_beta.onmicrosoft.com Tenant, where your domain company.com is currently added and verified.
4. Go to: http://portal.microsoftonline.com and log in with the newly created credentials.
5. Go to Office 365 settings-> Select "Become Admin" on the left. Follow the steps to verify that this user owns domain "company.com"
6. Add the DNS verification record as provided
7. Once DNS is verified, you will become the admin of that Unknown Tenant.
8. Now you can remove the domain from company_beta.onmicrosoft.com Tenant.

Once the domain is removed, please log out and logon to your new Office 365 tenant account, where you want to add the vanity domain.

Please follow the instructions to add the domain in Office 365

https://support.office.com/en-us/article/Verify-your-domain-in-Office-365-6383f56d-3d09-4dcb-9b41-b5f5a5efd611

SQL 2014 AlwaysOn Deployment for Skype for Business Server 2015

Ran through this in production for the first time using the excellent TechNet blog here.

Not going to reiterate much of that blog as it is fairly complete, but I hit a few errors along the way that I want to share.

1. Launching SQL 2014 PowerShell
   I searched a while for this.  Unlike Lync, AD and other PowerShell, there isn't really an import-module sqlps, even though several articles state similar.
   
   To Launch Powershell, you can either make a shortcut (YMMV on path) to:
   c:\Program Files (x86)\Microsoft SQL Server\120\Tools\Binn\sqlps.exe
   
   Or, in SQL Management Studio, right click and choose "Start PowerShell"
   
   Either option will launch the same process, and you will see then that the modules specified are loaded.
   
   
   
2.  Creating the Availability Group Listener
   
   When creating the Availability listener, I was receiving this error:The WSFC cluster could not bring the Network Name resource with DNS name '<DNS name>' online. The DNS name may have been taken or have a conflict with existing name services, or the WSFC cluster service may not be running or may be inaccessible. Use a different DNS name to resolve name conflicts, or check the WSFC cluster log for more information.
   
   
   This one was more due to it having been a while working on Cluster Name Objects (CNOs) - the issue is that the SQLCluster doesn't have permissions to the Computers CN in Active Directory, so you need to either add permissions, or pre-stage the computer object.
   
3. Adding permissions on the second SQL node in the AlwaysOn Cluster
   
   Within the last section of the linked blog on Technet, they state to run the install-CsDatabase cmdlet with the -update flag.  I did this repeatedly and was not seeing any updates applied, nor the permissions being added in SQL Management Studio.  After asking some colleagues, Someone recommended running S4B PowerShell as an Administrator.  Did this, reran the command and in made all the changes as expected.

Other than the above items, their article is VERY solid.   The scripting to do the SQL changes worked perfect and as expected, make sure to edit for your server and instance name! Also, the xCopy steps are a little tedious, if you instead plan on all your databases and logs being in similar directories, you just need to ensure those paths exist on both SQL servers.

Hope this helps!

Skype for Business, Lync 2013, Skype Directory and TCP/4443

Wanted to clear up a little confusion on this.   Thanks to other bloggers for posting the how-to on configuring the Skype Directory and of course the TechNet article on deployment.

After seeing several posts regarding additional port requirements, I decided to investigate further.  There are TWO port requirements for this functionality.  (there is not a "Consolidated Edge Port Summary for S4B Server yet, but here is the Lync 2013 article)

1. TCP/4443 from the FE pools to the Edges.  This should already be open in your environment for the failback A/V path and replication of CMS.
2. TCP/443 from the Access Edge service to the Internet.  Now, in most environments, TCP/443 outbound for HTTPS is not blocked for things like Windows Updates and Web browsing, but if you did have an environment that was extremely locked down, this would be a new port requirement.

 Now, during MS Ignite in early May, there were some postings and discussion about TCP/4443 from Edge to the Internet was required.  I have found that this is NOT true.  The S4B Server Protocol Poster confirms this.

This shows the only additional port requirements externally are TCP/443 from the Access Edge.  On the internal side, the TCP/4443 from FE to Edge is represented, but was already there in Lync 2013.

Now, looking at an actual S4B Edge server and running a  netstat -ano I can see that it is indeed listening on both the internal and external NICs on TCP/4443.  A telnet test and test-netconnection confirm that there is indeed a listener on both inside and outside interfaces.

So there is a slight discrepancy here that the port is listening, but is not documented as needed in S4B Server.  I also checked against a recently patched Lync 2013 Edge server - and the same configuration of listening on TCP/4443 is in place there as well.