The value of the BitTitan SDK to your Enterprise migration project

For those of you with consulting experience, specially in Enterprise projects, currently working in the migration business as a consultant, or in other roles, you’ll know that there’s a huge difference between small/medium size projects and enterprise projects, specially in the way the project is executed.

It’s usually very easy to use a user interface of a tool, to perform actions for 10, 20 or 50 users, but when you have dozens or hundreds of thousands of users to migrate, that quickly becomes a challenge. In this post, we’ll discuss some of the key areas where, leveraging the BitTitan PowerShell module as a key element for task execution in your project, will bring a huge value.

Automate reoccurring tasks

In enterprise migration projects you’ll have hourly, daily or weekly tasks that you have to perform, such as:

  • start/restart migrations
  • create reports
  • move users between migration stages
  • retry failed migrations
  • add new batch of users to migration project
  • schedule the Outlook profile reconfiguration for a batch of users

During your project, most if not all of the tasks described above will have to be executed multiple times a week or even multiple times a day, depending on the task.

So why should you automate those tasks? The answer depends on the task, but reasons should include saving man hours, making sure tasks get executed on time, link task executions (i.e move a user to a different project and start another migration pass), etc

Create your own reports or integrate with an external reporting system

The BitTitan user interface provides you a whole variety of “out of the box” reports, such as user migration statistics, user devices details, etc. But from my experience there’s always one or multiple reports, that you or your customer needs and there’s no easy way of extracting that out of any user interface. With PowerShell you can extract any information and combine them in custom reports, that you can build to cover the exact needs you have.

As an example, if you want the total number of users across all project with migrations completed, running, failed, completed with errors or queued, the best way to get that is via the BitTitan PowerShell. You can filter in the user interface and you can also send to your email the project statistics CSV, but that is done per project and it doesn’t scale, specially if you have a large number of projects.

Another example is to get item counts and sizes of successfully migrated items for all users in all projects. Again in the case you can use the project statistics CSV sent via email, but that does not scale if you have 50 projects and need that report twice a day, does it?

You can also leverage the information provided by PowerShell to feed a reporting portal, from where you can monitor all major aspects of the migration (like the ones mentioned in the above examples), and that PowerShell can update in short intervals of time (i.e every 5 minutes). That gives you the ability to synthesize the information that you consider most relevant and make it available to the entire team executing the project, as well as of course keeping it up to date, without human interaction, instead of for example having to compile it and send it via email multiple times a day.

Multi platform task execution

In the scope of an Enterprise migration project, the “BitTitan tasks” are just part of the equation. There’s much more to do than just move the data and reconfigure the Outlook clients. That being said, it’s very common for consultants to build and use complex scripting for Enterprise level migrations, that leverage multiple SDKs and PowerShell modules. Some examples:

  • Leverage the MSOnline PowerShell module to create users and assign licenses in Office 365 and after the task is checked and being completed, leverage the BitTitan PowerShell to start the prestage migration for those users.
  • Stamp forwarding addresses, either via Exchange online or Exchange on premises PowerShell modules, before triggering the full migration pass with the BitTitan PowerShell.
  • Verify that the BitTitan migration is completed, via the BitTitan PowerShell, and convert mailboxes to mail users or remote mailboxes, once the completion status is marked as successful.

The three examples above, highlight some of the most common tasks that require multi-platform execution, but it can get much more complex than that. You can automate task precedence and execute much more than just two tasks, leveraging all available PowerShell modules

Trying to link those tasks via the user interfaces, with human interaction, is very challenging and time consuming. They will of course require access to multiple user interfaces and during the execution you can’t automate the task dependencies, which will make it prone to error.

Optimize execution of complex or lengthy tasks

We talked about the benefits of automating reoccurring tasks, about multi platform task execution, but it’s also very relevant to mention task optimization for very complex or lengthy tasks. This doesn’t need to be a reoccurring task nor it needs to be cross platform, all you need to consider when you plan to code a task to be done via PowerShell is, “Can I remove a lot of complexity and execution time, if I run this task via PowerShell?”. If the answer is yes then, code it.

Removing the complexity will allow you to have literally anyone executing that task, and not just a senior resource in your project.

Removing execution time is self explanatory: It saves you money and helps keep you within the estimated project timelines, since it’s easier to predict a task execution time when it’s scripted vs when it’s executed by a human.

Now to put this into context, let me give you some examples of complex or lengthy BitTitan tasks:

  • Retry errors to all illegible users in a project with 10k users
  • Schedule DeploymentPro for users with 5 different vanity domains
  • Start a migration for a list of users provided via CSV
  • Create 25 MigrationWiz projects, one per each user batch
  • Create 10 MigrationWiz endpoints for multiple admin accounts
  • Add 5k recipient mappings into a MigrationWiz project

To be honest all of the tasks described above are more lengthy than complex, since in my opinion there’s not a lot of complexity in the BitTitan tools, nevertheless you might not want to have some lower level resources executing them.

On the other hand, all of the tasks above take a significant amount of time to complete and scripting them will save you a lot of precious hours.

Proactive monitoring and task execution

The BitTitan user interface already has some monitoring tasks, such as send an email to the administrator when a migration fails, but with PowerShell you can take monitoring and proactive task execution to the next level.

Instead of just notifying the project executor that a migration failed, you can trigger another migration retry, but you can go to the detail of only doing it if the failure reason is not something like bad admin credentials. You can make it as clever as you want.

You can also chose not to have to check your email, to see if migrations failed, and just create a script that every 30 minutes checks for failed migrations, checks the reason for failure and if it’s worth retrying, starts another migration pass.

The sentence above explains why I think proactive monitoring and proactive task execution are tied together. Let that sync in, imagine a project with 75 thousand users and with around 5 thousand concurrent migrations being executed at any given point in time, and think about how proactive monitoring and task execution can not only save you hundreds of work hours, but also keep your project timelines within schedule. The last thing that you want, in a large and complex migration project, is to lose hours of migration time, where nothing is being migrated for anyone, because an error occurred and the resolution time is high.

Summary

So how do you, based on everything you read above, plan an execute an Enterprise migration project, with automation?

Use a tool that you can automate with:

When you’re choosing a tool for your Enterprise project, you should heavily consider one that has a powerful PowerShell module, like the BitTitan tools do. You can check the BitTitan PowerShell documentation here.

Prepare and test all of your automation:

Make sure you have all your scripts ready and tested. If you need helped coding with the BitTitan SDK please reach out to me directly or to the BitTitan support, that will forward you to the appropriate department that will provide the help that you need.

And that’s it.. I hope this post has been helpful and please reach out if you have any questions!

 

 

Advertisements

Allow external RDP to your newly created Azure VM

One of the first things you do, after you create your new Azure virtual machine, is remote desktop into it.

Depending on the type of Azure environment you have, you might want to define the best access policy to the virtual machines, determining for example if you need to be connected to a VPN corporate network or not.

In my example, my Azure subscription is used for testing and therefore I will allow external access to my virtual machine.

It’s also important to understand that, to give remote desktop access to the virtual machine, what you need to configure are Inbound Port Rules in the network security group.

You have three options when it comes to configuring security access policies to a new Virtual Machine.

Option 1: Select the ports you want open, during the virtual machine creation

This is the simplest option, unless you want to keep things organized and manageable by using the same network security group for multiple virtual machines (see option 3).

When creating the virtual machine in the main menu you should see a section called “Select inbound ports”, after selecting the “Allow selected ports” right above that one.

InboundPorts01

All you have to do is select the ports that you want to open, for example 443, 25 and 3389 for an Exchange Server and the new network security group will be configured automatically.

Option 2: Create a new virtual machine with default settings. Once the VM is created edit the newly created Network Security Group.

This is the option you should follow in case you either forgot or chosen not to follow the option above and you didn’t selected an existing and already configured network security group, during the virtual machine creation.

A newly created network security group, should have the following Inbound Port Rules created as default:

NSG01

And what you need to do is add an inbound port rule.

You can do it via the azure portal, by either going to the virtual machine and then the networking section under settings and clicking “Add Inbound Port Rule” under the correspondent tab.

You can also go directly to the network security group (under all resources) and then the inbound security rules under settings and clicking “Add”.

NSG02

 

The above is how the inbound rule should look like. You can click in the “Basic” button in the top left to select from an existing service template. There’s an excellent article on how to open ports to a virtual machine with the Azure portal, that you might also look at for additional details.

Option 3: Create a new Network Security group and select it when creating the new virtual machine.

The other more advanced option is to create a network security group and use it for multiple Virtual Machines when you create them. That way you won’t have unique security groups per virtual machine and you won’t have to keep opening one or multiple services for those virtual machines, each time you create a new one.

I won’t go into details on how to create the network security group. For that just follow the official guidance on the link above.

Once you have your group created and upon creation of the new Virtual Machine, make sure you select it, instead of the default option to create a new one.

InboundPorts02

When creating the virtual machine, in the “Networking” tab, selected “Advanced” under “NIC network security group” and select an existing security group.

And that’s it. It’s a very simple process and one you need done if you want to start accessing those Virtual Machines or publishing services like HTTPS or SMTP. Hopefully after reading this post you understand the several options you have.

All of the above can of course be done via PowerShell, but to keep this post as simple as possible, I’ve used the portal.

Note: I want to make clear that you should not allow Internet unrestricted access to your virtual machine, unless it’s a test machine where you have no type of sensitive data. Even in those cases you can always easily set the source address or range of addresses for that inbound port rule.