5 Tips for Deploying Windows in the Cloud

By George Reese, CTO of enStratus

Deploying systems in a public cloud infrastructure places unique demands on how you manage your virtual servers no matter what platforms you use. Though security is generally the first thing to come to mind, you also have to deal with more mundane issues like software licensing, accounting, and differences in process management. With the launch of Windows support in the Rackspace Cloud in early 2010, I thought I’d share some tips for addressing the unique challenges Windows presents in a cloud environment.

1 – Learn PowerShell
PowerShell is the little-noticed gem of the Microsoft world. It’s a scripting language for the Windows platform that is more powerful than its Unix equivalents. Through PowerShell, you can automate any task in Windows—from adding users to setting up .NET applications to installing SQL Server data sources. At long last, you never need anything more than a command line in the Windows world.

PowerShell is so critical to the cloud world because the cloud demands scriptable automation. While you may be used to this kind of automation in the Unix world through bash or another shell, the ability to automate in Windows prior to PowerShell was very limited. Without PowerShell, managing a Windows environment in the cloud ranges from painful to impossible.

Some PowerShell tips:

1.    Windows 2003 Server requires you to download and install PowerShell on your own.
2.    Do not use a browser to upload scripts to your server unless you are prepared to sign those scripts.
3.    There is no great single source for learning PowerShell. There’s a lot of great information out there, but it is spread across several dozen web sites.

2 – Avoid the use of permanent user accounts
I am not fond of interactive user accounts with password-based authentication on servers in the cloud for a number of reasons:

1.    User accounts in the cloud have a tendency to get bundled into your backups and images from which future servers are launched. This creates a huge issue with terminating the accounts of employees/contractors who are no longer with your organization.
2.    Traditional directory services require trust relationships within the cloud that are not appropriate to the security profile of cloud-based systems.
3.    Password policy management in the cloud is difficult. The result is often weak passwords vulnerable to brute-force attacks.

At enStratus, we have developed an approach that places user accounts on a server only for a temporary period of time. A user logs into our portal and requests access to a target server. enStratus then (via PowerShell!) adds a user account on the Windows server. When done, the user removes their access. Because of this approach, interactive accounts are not permanently active on production servers and people don’t bundle user accounts into images. Later this year, we’ll make the passwords used to access Windows accounts “one-time passwords” and enable auto-expiration in case someone forgets to remove their access.

Whatever your approach, the objective should be to minimize the number of accounts you keep active on your Windows environments. If you take an approach that keeps active users on the Windows servers, make sure that part of your system recovery procedures include the wiping of user accounts from backups prior to restore.

3 – Watch out for the long Windows boot times
We often think of the boot times of Windows versus Unix as just one of those things you have to live with. In a cloud, however, you may constantly boot and shut down servers. The difference in boot times can grow to be quite painful.

While I don’t have any magic advice to reduce boot times, it’s still important to keep boot times in mind when configuration a Windows infrastructure requiring on auto-scaling. Longer boot times require lower auto-scaling thresholds.

Another aspect of longer boot times is the fact that more system changes require reboots on Windows servers than Unix servers.  It’s particularly important to take into account your “reboot strategy” when you are automating tasks that result in configuration changes requiring a reboot.

4 – Minimize web application dependencies
In other words, leverage as much of a basic operating installation as possible and keep all of your application components together with your web site deployment. Taking this approach, it’s very easy to automate deployment and backup (again, using PowerShell) of your .NET and other web applications in a manner that will rapidly port outside your target cloud. Applications requiring very particular Windows configurations are much harder to deploy in the cloud. In addition, it’s much harder to craft a DR plan for such systems.

5 – Remember to logout
Remote Desktop access is strictly limited in Windows. If you accidently leave RDP sessions running, it can often be very difficult to kill them so you can access your server. Many of the tricks you commonly use on servers you or a partner like Rackspace manage simply don’t work in a cloud environment. In short, always explicitly logout of your RDP sessions.

Before leaving in 2016, Angela ran integrated marketing campaigns for Rackspace. She started in 2003 and did everything from Linux support, account management, sales, product marketing and marketing. She left Rackspace in 2005 to work for PEER 1 Hosting but returned in 2009 because she was interested in the cloud computing movement. Angela is a strong believer in the power of storytelling.


Please enter your comment!
Please enter your name here