So what of the SysAdmin? Where does that leave the Jacks and Janes of all technological trades? What happens to the server room MacGuyvers fixing latency issues with chewing gum and a withering stare?

We’re not dead and gone yet, and we probably never will be, but would you be put off by a change of title? How would you feel being called a SysBroker? Or even SysSherpa as a recent BNet article inspired me to term it.

As companies look to the ubiquitous cloud for sustained growth with minimal cost, System Administrators will need to scrape the gloss off of the shiny brochures that the executives read to find the pitfalls and hidden costs lurking in the mists. Navigating the peculiarities of hosted services and cloud providers may very well be the internal SysAdmin’s biggest responsibility in the years to come.

Sure, EC2, Azure and many others offer cheap, commoditized compute power with amazing resiliency that would cost a royal mint to reproduce. Yes, it sounds like just the kind of amazing cost savings that executives are always pushing IT to deliver. However, will a given cloud provider interoperate with existing applications? Will a SaaS provider expose an API that is accessible in a way that your developers are versed in?

What about performance? How can you precisely measure performance when in many virtualized environments the underlying mechanisms that performance monitors require are abstracted away? What method is used to create the multitenant systems and how would that possibly affect performance? For example, as of this writing in mid-2010 Amazon EC2 uses paravirtualization while GoGrid uses hardware virtualization.

Cost is another labyrinth to navigate. How much does moving data cost? What’s the cost difference between transferring data from one cloud instance to another versus entering or leaving the cloud? How is cost tabulated? For instance, Amazon and many others charge a certain dollar amount per hour of operation, whereas providers such as Flexiant’s Flexiscale are paid for in points (which themselves are paid for in dollar amounts).

Are you getting the picture? All of these questions and many, many more need to be accounted for. When you look closer, the silver cloud has a slight grey outline that takes a seasoned IT person to distinguish and plan for (or steer away from as the case may be). The cloud is a great tool, but like any tool it can do more damage than good if not applied properly.

Someone needs to fan through the smoke and mirrors to determine what’s best for the company. That sounds a lot like what SysAdmins are known to do. In reality, the ideal SysAdmin’s mentality will not change and will never be obsolete. However, what systems we procure and manage while working within a company’s IT department will change greatly.

Instead of working out purchase orders for servers, racks, battery backups, failover software and all of the SysAdmin things that we are currently known for, we’ll be brokering resources from the cloud in the form of virtual instances (Infrastructure as a Service), SaaS and Platform as a Service. Many SysAdmins are already doing this to some extent, it’s just that it will become more and more what we have to manage each day.

It’s no different than the shift that took place when mainframes and proprietary iron gave way to commodity servers and the x86 architecture. SysAdmins changed with the times. And aren’t we glad we did? (Those of you still working on IBM System 370s may need to breathe into a paper bag for a while)

The cloud is all around us, and once the hype and confetti settles, we can see quite a useful tool that relieves the SysAdmin from many mundane duties. The question is, are you ready to be a sherpa? Or does the term SysBroker sound like something you’d rather avoid?

If you’d rather avoid being a broker, there are plenty of opportunities out there for you to exist in a more classic SysAdmin role, but you’d better be prepared to move to the cheese rather than grouse about someone having moved it. More on that in a later article.

The first step was the easiest – create around a hundred machines in different organisational units in active directory.

We needed this part as our Search wizard queries Active Directory for computers in the system. The user than can select the computers they wish to search for PST files. The grid where they are displayed and various features around selection should be tested, but at this stage it is enough if the computer is simply created in Active Directory. You can go to your Domain Controller, run “Active Directory Users and Computers” management console, right click on any container, select “New” and select “Computer”. This way you can create any computer in your AD tree without physically having it in your system. If one desires to create a larger amount of computers, doing it manually really shouldn’t be an option, in which case a simple .bat file solves the problem.

To create an OU where the new computer(s) should go:

dsadd ou "OU=[name_of_OU],DC=[name_of_domain],DC=[name_of_domain]"

For embedded OUs:

dsadd ou “OU=[name_of_OU_child2], OU=[name_of_OU_child1], OU=[name_of_OU_parent],DC=[name_of_domain],DC=[name_of_domain]”

To add the computer:

dsadd computer "cn=[computer_name],ou=[ou_name(s)],dc=[name_of_domain],dc=[name_of_domain]" -uc

And now that we have the window open anyway, to add a user:

dsadd user "CN=[user_name],OU=[name_of_ou],DC=[name_of_domain],DC=[name_of_domain]" -samid [name_of_user (SAM id)] -upn [user_name@fqdn]
-fn [First_name] -ln [last_name] -display "[display_name]" -pwd [password]

This enables us to test most of the basic grid functionality and enablement. In order to check that these non-existing machines are handled correctly when the PST agent is installed on them our developers created a “data faker”, that browses the AD tree to get all computer names and we can set all available statuses for the computers found. This data faker is used to simulate search results as well.

We usually do a script that creates these user/computer names with an incrementing counter, but in some cases it might be a collection of really nasty characters/deeply embedded OUs or other special cases.

*Coming up in Part 2 – Reka will cover scripts to create mailboxes in Exchange 2007, and how to modify access rights on them.