Simply finding the right objects and then updating their properties or implementing changes can be a cumbersome process. Many Microsoft systems engineers have developed their own shortcuts and conventions over the years for dealing with the administration of complex Active Directory structures. One tool that has been lacking, however, is the ability to write powerful scripts to manage Active Directory.

The good news is that the arrival of Windows Server 2008 R2 with PowerShell 2.0 and the Active Directory Module changes all of that for the better.

Powershell 2.0 and Active Directory Module

Of the many new features in Windows Server 2008 R2, PowerShell 2.0 is one that may finally be coming into its own. One of the key new features in PowerShell 2.0 is the addition of modules. Modules differ from PowerShell 1.0 snap-ins in that they are self-contained and do not require registration or installation. Rather, modules are imported into the shell via the Import-Module command. Modules can also be offloaded when they are no longer needed.

To use the Active Directory Module, there needs to be at least on Windows Server 2008 R2 Domain Controller running Active Directory Web Services (ADWS) in the domain. As an alternative, the Active Directory Management Gateway Service can be installed on Windows Server 2003 SP2 servers and Windows Server 2008 (non-R2) servers with or without SP2 installed.

For the most powerful configuration of PowerShell 2.0 with the Active Directory Module, you will want to be able to do your scripting remotely from your own computer, or other workstation. This does require Windows 7 in order to install the Remote Server Administration Tools (RSAT).

The Active Directory Module provides a powerful way to manage AD structures even across domains. Part of the AD Module is the PSDrive Provider which allows you to map to an Active Directory domain using whatever credentials are required via the New-PSDrive cmdlet. Users are connected to their current domain by default. The mapped rights persist for the entire shell session, even if it requires using different login credentials for several different AD domains.

Active Directory Scripts In PowerShell 2.0

There are many different commands included in the Active Directory Module. One count places the total number of new commands at 82. The most commonly used commands, however, are those that match up with the most common Windows Server Administrator tasks. The naming convention for Active Directory cmdlets dictates that each cmdlet start with “AD” in order to help separate the Active Directory versions from similar PowerShell cmdlets available in the base PowerShell.

Thanks to this naming convention, obtaining a list of all the Active Directory Module cmdlets can be done by running the Help *-AD* command.

The most difficult part of getting up to speed with Active Directory management via PowerShell 2.0 is mastering all of the parameters available for each cmdlet. In an effort to allow virtually any function that can be performed manually to be scripted, Microsoft had to provide a working parameter for pretty much every setting, checkbox, and field that there is in the GUI. That means that some commands have a mind boggling array of available options. Fortunately, only a small subset of any cmdlet’s parameters are mandatory in order to run the desired command.

As with any new programming language, the key is to focus in the beginning on the basics and most frequently used options and build mastery as you go along. While it may seem daunting at first, one will quickly find that using built-in cmdlets specifically designed for their purpose ends up being much easier to both code and manage than mastering all of the work-arounds and band-aids currently required to perform the same tasks.

Common Active Directory Cmdlets for PowerShell

The most common administrative tasks within Active Directory are those that relate to creating, finding, and changing objects and users. Not surprisingly, these cmdlets make a great place to start learning and using PowerShell 2.0 to manage Active Directory.

Commonly used PowerShell AD cmdlets include:

• New-ADUser
• New-ADGroup
• New-ADComputer
• New-ADOrganization
• New-ADServiceAccount
• Unlock-ADAccount
• Enable-ADAccount
• Disable-ADAccount
• Get-ADUser
• Add-ADGroupMember
• Get-ADGroupMember
• Get-ADForest
• Get-ADDomain
• Get-ADDomainController

Of course, the real power from scripting comes not from typing in a bunch of esoteric computer commands instead of clicking mouse buttons, but from the ability to save useful scripts and use them over and over again. To this end, Active Directory cmdlets support piping information into the cmdlets. For example, to create a couple dozen new users, the administrator could take the Excel Spreadsheet supplied from Human Resources, export it as a CSV file and then pipe the resulting data to the New-ADUser command: Import-CSV c:\neweuserdata\april-new-employees.csv | New-ADUser and let the script take care of all the basic data entry.

Using parts of the same file, the admin can go back through and using the appropriate cmdlets add users to their respective groups and domains and even apply additional group policies to the new users.

Of course, easy, but highly repetitive tasks can be automated as well. Imagine picking up the phone with a call from a panicked user who has locked himself out of his account (again). A tiny shortcut launched directly with minimal typing and clicking requiring nothing more than the user’s login name quickly firing off and unlocking or even re-enabling the account, all without ever having to leave the screen you were already working on when the phone rang.

PowerShell Resources

Even though the Active Directory Module is new with PowerShell 2.0 there are already some great references available for Microsoft server administrators. Check out Jonathan Medd’s Active Directory PowerShell Quick Reference Guide for help getting up to speed and remembering lesser used commands. Microsoft has a general PowerShell Quick Reference guide as well. For those of you lamenting the hours spent mastering VBScripting, check out the VBScript to Windows PowerShell Conversion Guide.

Learning new technology and skills is never easy, but the truth — if we are willing to admit it — is that as high-tech computer administrators, we quickly grow bored with doing the same things over and over again. Not only does PowerShell 2.0 and the Active Directory Module provide some new material for the skills menu, it also provides a way to eliminate far more tedious, repetitive tasks than ever before.

Related posts:

• PowerShell 2.0: Server 2008 R2 Top New Management Feature
• Take Command of Server 2008 with Windows PowerShell – Part 1
• Don’t be Afraid of PowerShell

PowerShell 1.0 gave systems administrators around the world a new administration tool when it was introduced with Windows Server 2003.

For years, Microsoft has worked to develop a graphical user interface, or GUI, that would make system administration and user administration easier and more user friendly.

In many ways, the company succeeded admirably.

Most admins know at least one or two people who have managed to create a user in a very small Windows Server environment through User Manager and think that they should become a Windows Administrator because they already understand “how to do it.”

However, for administrators in environments where users exceed the number of people it takes to field a couple softball teams, things  are more complicated. In fact, one of the difficulties of properly administering a networked operating system and its servers is keeping all the “little things” consistent across the enterprise. Forgetting a check-box here, and a radio button there, can add up to a security nightmare waiting to happen, or perhaps, a very angry Vice President unable to remotely connect at a critical time.

The solution to some of these problems has been scripting. By writing scripts, Windows system engineers could ensure that repetitive tasks happened correctly and with far less effort than doing them manually. Everything from creating new user accounts, to installing software and upgrades, to basic login scripts has been coded somewhere along the way by a savvy systems admin looking to avoid headaches and spend a little less time on repetitive tasks.

Eventually, new Windows Server features and enhancements began to outstrip the capabilities of the DOS-based scripting that server administrators had been cobbling together. Fortunately, new tools and utilities were also developed that helped reduce some of the reliance on login scripts. For example, User and Group profiles have long since made mapping drive letters via login script obsolete. However, administrators still needed a more powerful scripting environment.

PowerShell 2.0 Upgrades Features and Capabilities

PowerShell has been slightly underrated within the administrator community. One reason is that in order for PowerShell to really perform throughout the enterprise, it needs to be usable on the servers and all the desktops.

Fortunately, Windows 7 comes ready to execute PowerShell scripts. Windows 7 SP1 is set to ship in the near future, which sounds the bell for many long-time IT professionals who live by the rule to always wait for SP1 before upgrading, and Server 2008 R2 comes with PowerShell 2.0 installed by default. As Windows 7 is installed in the enterprise, PowerShell 2.0 will grow even more useful.

Another reason PowerShell has not gotten its fair share of affection from systems administrators is that there were a few nagging things about how PowerShell worked conspiring to make it seem less powerful than it actually was. However, Microsoft has addressed many of these issues and thrown in a few new features as well.

Let’s take a look at some of these new features now.

Remoting

Nothing has been a bigger thorn in the side of PowerShell than Remoting. Remoting is the ability to run commands via PowerShell on remote computers. Technically, some remoting was possible in PowerShell one, but it was limited to the Get-WMIObject cmdlet within Windows Management Instrumentation (WMI). Even worse, WMI required RPC connections which meant having to go to the networking guys to get ports opened and firewall exceptions allowed. Not fun.

PowerShell 2.0 allows administrators to run commands on remote computers using the WS-Man (WS-Management) protocols which establish secure connections to remote computers using ports 80 and 443 by default. In many environments these ports will already be open, and in those that they are not, they’ll be a much easier sell to the networking team.

There is one little catch to remoting in PowerShell 2.0. In order to use remoting, it must be enabled on both machines. However, this only needs to be done once. Once enabled, remoting can be used on multiple machines at the same time allowing the administrator to execute the same commands on several computers at once. The applications for this ability are limited only by the admin’s ability (and the availability of the right cmdlet).

New cmdlets

Speaking of cmdlets, PowerShell 2.0 comes with over 100 built-in cmdlets. While this covers a lot of ground, there is no doubt that Microsoft Server administrators will quickly find functions and tasks that require other commands. Fortunately, Microsoft has implemented a way to handle this eventuality as well.

Modules are also new to PowerShell 2.0 and allow script developers to organize code into self-contained reusable units. This functionality has already been used to create a PowerShell 2.0 Active Directory Module which brings more possibilities to managing Active Directory via PowerShell.

Run Background Jobs in PowerShell

Another big addition to the PowerShell feature set is the ability to run background jobs. This means that those PowerShell scripts that take a long time to run can continue to perform in the background while the command prompt returns control immediately to the console.

An admin performing numerous tasks late at night can get them all running right away instead of having to wait until 2:00 AM to run that last command. This is especially useful while remoting multiple machines, especially when those machines are separated by various network connection speeds.

System Events Integration

PowerShell 2.0 now offers the ability to monitor and act on system events which can allow for more proactive scripting.

PowerShell ISE GUI

The most curious edition to PowerShell 2.0 is the PowerShell GUI, which, on the surface, appears to defeat the whole point of PowerShell. However, the GUI is really more of a basic script editor complete with color coded syntax, partial execution, stepping, and graphic debugging. The GUI also includes context sensitive help which can save admins from scanning through the verbose output of some help commands.

With Windows 7 coming to many businesses in the near future and the upcoming release of Windows Server 2008 R2 SP1, PowerShell 2.0 will be already waiting to go for enterprise-wide control and administration. The time is now for Microsoft systems engineers and administrators to learn how to take advantage of PowerShell 2.0.

PowerShell 2.0 Demonstration

Take a look at the video below to see a short demo of PowerShell 2.0.

Related posts:

• Active Directory PowerShell Scripts Management Tool For Admins
• Don’t be Afraid of PowerShell
• Take Command of Server 2008 with Windows PowerShell – Part 1

Server 2008 is easier to deploy and has added reliability. Security has increased enabling you to create a policy driven network that will keep your servers, data, and business safe.

Improvements in virtualization help to consolidate servers and make more efficient use of hardware.

There are also many enhancements to terminal services. Web administration is much easier from diagnostics and development to applications. Plus there are enhancements with the latest version of Internet Information Services.

Those who are creating a new Server 2008 R2 network from the ground up, can take advantage of all of these enhancements and more.

7 Server Management Improvements in Server 2008 R2

Today we’ll focus on seven improvements in managing your network, which is one of the most time consuming tasks for any network admin. Fortunately, Server 2008 R2 has several improvements in server management that will make your job much easier.

Here are the 7 server management improvements we’ll cover today:

1. Server Manager — the first one is the improved server manager itself, which makes administration of a single server a snap using the integrated Microsoft Management Console (MMC).
2. Windows PowerShell — management of multiple servers can be automated using the Windows Power Shell command line scripting language.
3. Windows Deployment Services — is an updated version of the Remote Installation Services which is used to set up new workstations and servers.
4. Windows Reliability and Performance Monitor — makes it easy to monitor system performance.
5. Data Center Power Consumption Management — improvements in the methods of reducing power consumption.
6. Remote Administration — enhancements for remote management through graphical management consoles that integrate with Server Manager.
7. Identity Management — which helps keep your network as secure as possible.

1. Server Manager

Server Manager is installed by default as part of Server 2008 and it is available to you as long as you are logged on to the computer as a member of the Administrators group. Using the new Server Manager streamlines the process of installing and configuring servers in an enterprise environment. When you first begin server installation, the Initial Configuration Tasks (ICT) will guide you through the initial process of setup.

In the past when installing and configuring a new server you would have to use different components such as Configure Your Server, Manage Your Server, or Add or Remove Windows Components to add or remove server roles or other software. Configuring new servers also took a lot longer because dependency components needed to be installed manually and server roles could only be installed one at a time. Also each installation had to be completed before the next one could start.

Using the Server Manager console in Server 2008 you can view all of the information about your servers, server configurations, and installed roles and features. You can also install new servers, add roles, and change configuration settings in one place at one time. Not only that but the Add Roles Wizard will automatically check for dependencies and install required services.

If the installed server role requires additional configuration then the Add Roles Wizard will provide configuration pages that allow you to correctly configure the role as part of the installation process. This is especially useful when installing Terminal Services or Active Directory Certificate Services.

Recommended security settings are also configured by default allowing you to have your server completely ready for deployment in one session. These improvements in Server 2008 make server installation and configuration easier and faster.

2. Windows PowerShell

Windows PowerShell is a scripting environment that uses Cmdlets. Having the power to run scripts can increase automation and make large scale configuration fast and easy.

Because PowerShell has standard Cmdlets that can be combined to create powerful functions, you can run scripts without having to know how to program. To find out more about Windows PowerShell you can always visit the Windows PowerShell Script Center where you will be able to find Cmdlets for common administration tasks as well as information on how to create your own Cmdlets.

To use PowerShell you need to install it and then run PowerShell.exe after which you will get a command screen that looks a lot like a DOS window and all you’ll have to do is type in the Cmdlets you want to run. If you would like a list of Cmdlets you can always type in Get-Command and you will get a list of all of the Cmdlets.

PowerShell is especially useful for remote desktop management and configuring Internet Information Services 7.5.

3. Windows Deployment Services

Windows Deployment Services, the updated and redesigned version of Remote Installation Services (RIS), is a suite of components that work together on Server 2008 R2 to enable the deployment of Windows operating systems.

WDS can be used to set up new computers using a network-based installation, which means that you don’t have to be physically present at each new computer and you don’t need to use a CD or DVD. The new service also has imaging capabilities which means you don’t have to use a third party software such as Symantec Ghost to copy your configured OS onto each new machine.

4. Windows Reliability and Performance Monitor

In order to maintain a network you need to know how well it is functioning, this is where the new Windows Reliability and Performance Monitor really shines. Instead of having to scour over several different tools such as System Monitor, Performance Logs and Alerts, and Server Performance Advisor, you can now collect all of your data from one single tool using a graphical interface.

Other enhancements include Data Collector Sets which are reusable and make scheduling and collecting data, fast and easy. There are also easy to use wizards and templates for creating logs, a resource view, and a reliability monitor with user-friendly diagnostic reports.

5. Improved Data Center Power Consumption Management

Power consumption in data centers is increasingly becoming an issue, not only because of cost considerations, but because there is only a limited amount of power for all of the computers in the larger data centers.

Windows Server 2008 R2 has three main methods of reducing power consumption. The first method is Core Parking which tries to reduce the number of processing cores used with multicore processors. Power consumption is also reduced by adjusting processor speed to reduce consumption while still maintaining maximum effectiveness. The final method used to reduce power usage is centralizing storage though the use of a Storage Area Network (SAN).

6. Improved Remote Administration

Server computers are rarely administered locally, that is why improvements in remote administration are so important. Server 2008 offers several enhancements for remote management through graphical management consoles that integrate with Server Manager.

And the improvements in PowerShell make remote administration using scripts much more efficient and easy to implement.

7. Improved Identity Management

Identity management is always a huge security concern. Server 2008 R2 includes identity management improvements in the Active Directory Domain Services and Active Directory Federated Services roles. The purpose of these enhancements is to keep the network secure on-premises and off-premises, keeping all access points secure from all users while extending security across the entire network, while at the same time simplifying user account management.

Managing a network is still a lot of work and a big responsibility but with the new improvements in Server 2008 R2 that responsibility is beginning to get a little easier. Having a single console for server administration along with an easier to use scripting tool and easier remote deployment will make the daily admin tasks easier.

Combine that with improved performance monitoring, power management, and increased security and remote administration and the upgrade to Server 2008 R2 will begin to make sense.

Related posts:

• PowerShell 2.0: Server 2008 R2 Top New Management Feature
• Active Directory PowerShell Scripts Management Tool For Admins
• Active Directory Improvements in Windows Server 2008

PowerShell is Microsoft’s newish extensible scripting language and corresponding command line shell. PowerShell was specifically made for IT professionals to achieve greater productivity and control system administration more easily. 

What PowerShell Can Help You Do

The thing is, PowerShell can do pretty much anything except walk your dog for you. You can even check the date and time if you really wanted to. I guess you could stop using the command line all together and do all your cmd tasks from within the PowerShell shell.

However, the real fun comes in when you can use PowerShell to make your sysadmin life easier. Here are a few random examples:

• Inventory your servers like what each has, the free memory, what service pack it is running, and so on.
• Add multiple users at once to your AD and then give them all a mailbox in Exchange.
• Back up and sync certain files then email yourself a corresponding log file…every night.
• Test out those scary commands before committing to them using the Whatif feature.
• And maybe the most compelling thing: You know how in Server 2008 R2 you can recover an AD object from the recycle bin after you have – oops – deleted it? Well you won’t find that option anywhere in the GUI. You need PowerShell to do it. If that isn’t a reason to give PowerShell a try then I don’t know what is!

For the Newbies

Good News! You don’t need any prior programming experience to use PowerShell — it is that intuitive. But, just so we are on the same page here is a short vocab lesson:

• Shell – What you the user actually interacts with. Either a command line or a GUI (graphical user interface).
• Extensible – The ability of a system to grow and change as needed.
• Scripting Language – Well, there are numerous debates going on all over creation about the difference between a programming language and a scripting language. You don’t really need to understand the specifics to understand that PowerShell is a language that you use to do administrative tasks. Who cares whether it is interpreted or compiled?
• cmdlets – Pronounced command-lets. Cmdlets are simple tools that can be used separately, but their power is realized when you combine these simple tools to perform complex tasks. Microsoft provides buckets of built-in cmdlets  but you can write your own if you see fit.

For the People with Programming or Unix Experience

Not surprisingly PowerShell has all the comforts of home: man pages, aliases, wildcards, and pipelines; if statements, recursion, and loops.

If you have worked with VB or WHS then you should be able to make the translation pretty easily. There is even help for translating your existing VB scripts to PowerShell.

PowerShell Resources to Get You Started

1. Take Command of Server 2008 with PowerShell — a short series of articles that provide a good introduction to PowerShell
2. PowerShell FAQ provided by Microsoft
3. Professor PowerShell Jeff Hick’s educational column on MCPmag.com
4. Windows PowerShell Owners Manual a free guide to getting started with PowerShell
5. Scripting with Windows PowerShell a list of resources for sysadmins interested in learning about PowerShell
6. Windows PowerShell Blog with information about the latest advancements in PowerShell
7. Windows PowerShell Cookbook providing you with recipes to do specific tasks with PowerShell.
8. Windows PowerShell 2.0 will teach you just about everything you ever wanted to know about PowerShell (and more)

 Good luck!

Related posts:

• Take Command of Server 2008 with Windows PowerShell – Part 1
• Active Directory PowerShell Scripts Management Tool For Admins
• Take Command of Server 2008 with Windows PowerShell – Part 2

However, Microsoft did just release SP2 for Windows Server 2008. Can IT get just as excited about the new server OS?

Here are five great things about Windows Server 2008 and information that will help you decide if upgrading is worth it.

1. Virtualization

Server 2008 comes with Hyper-V a virtualization technology that runs natively on Server 2008. New licensing terms that better align with business in the real world are a huge plus, but the improvements don’t stop there.

While load-balancing is probably still usually best done via a hardware solution, the virtualization in Server 2008 provides numerous opportunities to give flexibility to those with large or complicated infrastructures. Being able to create a new virtual server running a software upgrade or new install on it while leaving the old one completely functional is an enormous boon to the savvy IT department.

If there is any trouble with the new virtual server, the old virtual machine is rolled back in its place, allowing for more testing or troubleshooting while having to worry about neither too much downtime, nor taking too long to roll out new systems caused by “over-testing.”

2. Core Server Installs

Sometimes all you need is a server to sit there and handle just one little thing, and nothing else. In times past, that meant “wasting” a full server installation to handle little, but critical tasks. Securing those servers and then keeping all the patches and upgrades current often seemed like more trouble than it was worth.

Thanks to Core Installations of Server 2008, you can create a Windows Sever that not only does just one thing, but is only capable of doing that one thing rendering it a much less vulnerable system whether to bugs or attacks.

Even better, Server 2008 is smart enough to only bother applying patches that apply to what is actually installed and running on the core server which eliminates numerous updates from ever having to run (and possibly harm) these core servers.

3. Read Only Domain Controllers

Somewhere along the line, domain controllers ended up scattered across many enterprises primarily for speed and fault-tolerance purposes. Generally, while perhaps a slight overkill in many situations, this practice was relatively harmless.

Then, somewhere along the way, the physical security of domain controllers became an uncontrollable factor as remodels or personnel changes left domain controllers sitting under the receptionist’s desk or in the corner of a conference room. While not a widely used tactic, compromising a domain controller and then using its replication features to infest an entire Active Directory with numerous administrator level accounts became a real fear.

Fortunately, the Read-Only Domain Controller solves this problem by allowing for placement out in the field beyond the control of corporate IT but without the ability to send any junk data back into the main network.

4. PowerShell

Real administrators never stopped using the command line to manage servers. Between scripting repetitive or error prone tasks, to just flat out getting something done fast without having to load up any point and click GUI — firing off commands with a few keyboard strokes has always been useful.

But, with PowerShell even admins who gave up the command line are coming back. Doing something to multiple servers is easier than ever with PowerShell. And even better, those 2:30 AM pages from the monitoring system can be addressed remotely from the command line without even putting on your robe, especially if you pre-write some scripts before anything happens.

5. TS RemoteApp

When I first read about TS RemoteApp I was underwhelmed. Frankly, I liked the idea of having a remote desktop and then picking and choosing what to run there. Apparently, that is a system admin mentality.

For users, nothing could be more confusing that having a remote desktop in addition to the local one. After the 800^th user asked me which desktop was their “real” desktop, I realized the value of TS RemoteApp.

With RemoteApp, an application is run remotely, just like the old days, but the big difference is that it launches straight into the application, no desktop, no “second” double-click, no confusion about where the files “really” are located.

Windows Server 2008 Upgrade Is Worth It

Add in all of the performance and stability improvements that Server 2008 brings to the table and you have yourself a solid server OS upgrade.

Many companies will follow the tried and true method of upgrading as new hardware comes online. However, there are many instances in which certain applications, certain server functions, and certain servers outside of the corporate IT server rooms would benefit from an upgrade to Server 2008.

In those cases, it is worth it to schedule upgrades ahead of the hardware lifecycle. Also, with server power increasing faster than many enterprises take advantage of it, waiting for a hardware based need might mean waiting too long.

A smart solution is to evaluate your current server environment and evaluate which servers could benefit most from an upgrade to Server 2008 because of additional needs or limitations that the current servers have. Once those servers have been taken care of, move on to your newest and most powerful servers.

Chances are that they are not being fully utilized. Those servers are prime candidates for Hyper-V and taking on more functionality and responsibility. The same servers will of course be the ones the furthest away from hardware needs based upgrades as well.

Working ahead on sever OS upgrades in this manner can shorten the overall migration time while still providing minimal disruption to the currently functioning server environment, and that is a Win-Win for everyone involved.

Related posts:

• Overview of Server 2008 R2 — The Half Version Upgrade
• Windows Server “LongHorn” Certification Upgrade
• Install Read-Only Domain Controller on Windows Server 2008

Microsoft also provided its first look at what will become Windows Server 2008 R2.

For those of you who just wait until software starts shipping and don’t pay much attention to things like software release strategy, here is a quick primer.

Microsoft has long been a player in the corporate and desktop software and applications space. Just a decade ago, there were only a few competitors in that space, and they all played by the same rules when it came to upgrades.

Basically, a company built its best software product possible based on the needs and possibilities of the day and then released it to be sold to the public. After doing so, the company would begin the process of adding in new features, or optimizing the code, or supporting more systems.

The paradigm was such that this process should be completed over a period of a certain number of years depending upon what kind of software it was. For Microsoft, releasing operating systems spanned a several year gap.

Part of the reason for this was that deploying new operating systems was a particularly large undertaking and companies were not interested in having to do it very often.

Thus, Microsoft brought out new Windows Sever products every 5 or so years. (They claimed to have a 4 year goal, but they always ended up late.) These days, that doesn’t cut it.

Thanks to advancements (some of them Microsoft’s own) in deployment methods, as well as the "new features now" and methodology brought on by many Internet vendors — a five year gap in upgrades is just too long.

However, Microsoft doesn’t want to have the pressure of having a "big enough to be almost new" upgrade every 2 years. So, they have proclaimed that they plan to release their Windows Server operating system and then approximately two years later release a mini-upgrade, or a "release two" version of the software.

This strategy allows for the addition of new features that come about after the release of the main upgrade, without having to start over from scratch.

The Windows Server 2008 main release was, not surprisingly, in 2008, so Microsoft plans a Release Two sometime around 2010.

The developers at the PDC were given a sneak peak version of R2 along with the Windows 7 desktop code which was more heavily noticed. The biggest news is that Windows Server 2008 R2 is actually called Windows 7 internally.

No, nobody is asleep at the wheel. Microsoft is, for the first time since Windows 2000, developing both systems in tandem.

This coupled with the news that Windows 7 desktop is based entirely off of Vista shows that Windows Server 2008 R2 will end up being very tightly integrated with Windows 7 (or Vista 2, if you will) when it is released.

Unless a company likes the idea of turning over both the desktop OS and server OS at the same time, this puts a huge damper on the idea of skipping Vista.

What Features Are In Windows Server 2008 R2

Obviously, at this point, everything must be considered conjecture, but we do have a pretty good idea of what Microsoft is working on for its mid-release upgrade.

First, is the confirmation that Windows Server 2008 R2 will come in x64 flavors only. Although becoming more of a moot point by the day, it does affect some operations, particularly those where "tiny servers" that perform only a single simple process are housed on older machines.

The second piece of big news is that PowerShell development is rushing forward full speed. PowerShell is available, and very useful in the current Windows Server, but they are adding hundreds of new commands across almost all the roles, so some of the things that are beyond PowerShell’s reach today will be well within grasp in R2.

Other news includes the bump in server cores support from 64 to 256, adding support for .NET to the Server Core, significant improvements to IIS, and (yea!) the ability to access other servers from Server Manager.

Virtualization

Perhaps the most visible feature of Windows Server 2008 from an administrator point of view was virtualization. Hyper-V is available on Server 2008 as a role today, but in the future will be integrated into the OS (you won’t have to wait for R2, it is in SP2.)

The biggest deal here is the ability to migrate virtual machines to another server without downtime. VMware already can do this, so it will be nice to have the same feature available in R2.

Ah, the dream of every sys admin, the ability to perform hardware maintenance and upgrades without having to come in at 3:00AM after pre-announcing the downtime three to five weeks in advance after a thorough change control process.

Also, in the works is the ability to "hot add" virtual hard disks without rebooting the virtual machine.

All in all, it seems like R2 will be a very worthy release for most environments. Of course, that means that it will be even more useful to nail down some of those Windows Server 2008 features that have been left on the back burner so that when R2 shows up, there won’t be any catch up needed.

Related posts:

• 5 Great Things About Server 2008 — Is an Upgrade Worth It?
• Server 2008 R2 Update Review
• Windows Server “LongHorn” Certification Upgrade

In this day of powerful servers just an inch thick, it is easy to forget that just ten years ago a server was a very large computer. Each server cost thousands of dollars so the idea of “wasting” an entire server on just one or two functions was ridiculous.

File servers also served as domain controllers, and print servers, and WINS servers, and DHCP servers, and so on.

Managing severs meant going into the server room and accessing the server via its own keyboard and monitor. And, when Microsoft released a patch you installed it on every server in your enterprise.

Although the earliest servers did little more than allow files and printers to be shared while providing some basic user authentication, with each successive version, more functions were added. Each new function increased the resource requirements, as well as increasing the complexity of managing all of those functions.

Modern Networks

Fast forward to today’s modern network environments where servers are managed remotely, and are routinely configured to perform just one specific task. In other words, all of the features of a full blown Windows Server install are no longer used by many servers. This is where the Windows 2008 Server Core Install comes in.

The Windows 2008 Server Core installation installs only the bare minimum of resources and functions. Minimum really means minimum.

There is no start bar, no Windows Explorer, no desktop shell, no PowerShell, no .Net framework, no Server Manager, no MMC Console, no Administrative Tools, and most of the Control Panel applets are missing as well.

So how do you manage a Sever Core?

Old school: using the command line and scripts. Anyone managing a Core Server will want to bookmark the A-Z command-line reference right away.

If you have trouble with this link, just go to Microsoft’s website, the A-Z command-line reference is under: Windows Server TechCenter > Windows Server 2003 Technical Library > Windows Server 2003: Product Help > Windows Server 2003 Product Help > Administration and Scripting Tools > Command-line reference or on Technet under “Windows Command-Line Reference A-Z”

You can also manage some (but not all) of the server functions remotely with the familiar MMC. So why would anyone do such a thing?

Fewer Resources, Better Security, Easier Maintenance

For starters, the Core install requires far less resources than the full install. Just half the disk space of a full install is required and the Core server can technically run on less than the “required” 512 MB of RAM (as little as 100 MB if no server roles are installed). Unfortunately, the setup program cannot run on less, so for practical purposes the minimum is 512 MB.

Even though most servers in the corporate environment today far surpass these minimums, if the operating system isn’t using those resources, then your programs can be using them which means faster response times and fewer resource management problems.

Equally important is the increased security such an installation provides. After years of locking down user accounts, group policies, and network connections, attacks no longer occur along the “front lines.” Gone are the days when hackers accessed servers via a brute force password program, or copying off the file containing user accounts.

Now, hackers gain access to servers by exploiting the inevitable flaws that creep into program code that stretches for millions of lines. An attack that allows unauthorized access by creating some sort of buffer overrun in the DHCP server process cannot be successful against a server that does not even have the DHCP code installed anywhere on the machine.

A Core Server installs approximately forty services by default versus nearly seventy-five services on a full install. That makes thirty-five fewer points of attack. This smaller footprint provides fewer targets not only for hackers, but for viruses and other malicious code as well.

Along with the increased security, a Core Install reduces the number of patches and updates that must be applied. Again, if the code does not even exist on the machine, there is no need to patch it. Indeed, there would be nothing to patch!

Microsoft has implemented the Server 2008 code in such a way that administrators will never have to sort through the various patches. All Server 2008 patches will be coded with applicability rules.

If the subsystem being updated does not exist on the server, the patch will automatically not be run. Preliminary data from Microsoft suggests that a Core Install would reduce server patches by 50% over a full install.

Server Roles

While decreased use of resources and better security are great, it isn’t much use if the server cannot perform a meaningful role in the enterprise. Therefore, the Server Core install can be extended by adding certain roles to the server.

In essence, the server becomes a “Core Plus” server. That is, a Core Sever plus the code for the additionally installed role. For example, a file and print server installed at a remote office with just a few users can be setup as a Core Plus File/Print Server.

Under this methodology, there will never be a need to manage, review the logs, or patch the Active Directory systems on that server. As a bonus, the server will run with considerably less overhead.

Available Roles for a Core Server Install are:

• Active Directory Server
• Active Directory LDS Sever
• DHCP Server
• DNS Server
• File Server (DFSR & NFS)
• Print Server
• Streaming Media Server
• Windows Virtualization Server

Most other roles cannot be installed on a Core Server and would require the full server code due to dependence on multiple subsystems or APIs.

Additionally, certain features can optionally be loaded on a Core Install including: Bitlocker, Failover Clustering, Multipath I/O, Removable Storage Management, SNMP Services, Subsystem for UNIX-based Apps, Windows Server Backup, Read Only Domain Controller, and WINS Server. Again, most other features would be unavailable.

Chances are many environments have servers acting in this fashion right now. It is likely that a DNS Server is not also handling print services.

With the Core Server installation such a server is transformed from being a fully installed server that allows a lot of code to sit unused into a server that only has the code it needs installed.

By providing the Core Install option, Microsoft has answered critics who complain about continuously bloating software and administrative overhead, while at the same time providing a valuable tool for arsenal of the design of enterprise architecture.

Related posts:

• Role Playing with Windows 2008 Server Core
• Server Core Install vs. Full Install – Let’s Get Ready to Rumble!
• GUI Schmooey –- Installing Windows 2008 Server Core

You’ve made it this far, so I’m assuming you enjoyed part one, where I showed you how to install and access PowerShell, and part two, where I explained PowerShell Cmdlets and PowerShell Providers.

If you missed those two articles, I would suggest reading them first — just to make sure you’ve got all the basics. Now let’s get started with an exercise in customizing your Windows PowerShell.

Customizing Windows PowerShell

Windows PowerShell starts with the same look and feel of the Command Prompt, by default. Let’s make our first exercise of PowerShell power be to customize the PowerShell console.

The steps below will walk you through customizing the console options then saving those settings to be used every time PowerShell is launched.

1. Open Windows PowerShell

2. Create a variable to the PowerShell RawUI object with the command below:

$psui = (get-host).UI.RawUI

3. Use the $psui variable to change the background and text colors with the commands below:

$psui.WindowTitle = “PowerShell PowerStation”
$psui.BackGroundColor = “Blue”
$psui.ForeGroundColor = “Yellow”

Note: The PowerShell console supports 16 colors. They are; Black, White, Blue, Cyan, Gray, Green, Magenta, Red, Yellow, DarkBlue, DarkCyan, DarkGray, DarkGreen, DarkMagenta, DarkRed and DarkYellow.

4. Use the cls command to clear the console and fill the console with the background color specified

5. View the other properties available to the object by entering $psui

Note: If you wish to change RawUI objects with multiple properties such as the BufferSize property you must assign the property to another variable to modify the object’s properties like the example below:

$psbs = $psui.BufferSize
$psbs.Height = 3000
$psbs.Width = 120

6. Decide on how you want to customize the PowerShell console with the properties available

7. Open your PowerShell Profile with notepad with the command below:

notepad $profile

8. Assuming that you are running Server 2008 and this is the first time creating a PowerShell profile, Notepad should display an error that the file was not found.

Click Ok to close the error and return to PowerShell to rectify the problem.

9. Try using the command below to create the profile file:

create-item $profile –type “file”

10. The previous command attempts to create the profile file under your ‘Documuents\Windows PowerShell’ directory, but with no Windows PowerShell directory, no file was created

11. Use some PowerShell power to create the directory then the profile file by entering the commands below:

new-item $profile.SubString(0, $profile.LastIndexOfAny(“\\”))
create-item $profile –type “file”

Note: If you have any experience with the .NET framework the first command of this step should look familiar. It utilizes the methods of the string object to parse the profile path out of the profile variable.

12. Open the newly created file by entering notepad $profile again

13. Enter the property changes as you would in PowerShell into the profile file. Below is an example of the contents of a profile file with the same setting examples in these steps:

$psui = (get-host).UI.RawUI
$psbs = $psui.BufferSize
$psui.WindowTitle = “PowerShell PowerStation”
$psui.BackGroundColor = “Blue”
$psui.ForeGroundColor = “Yellow”
$psbs.Height = 3000
$psbs.Width = 120
cls

14. Click File | Save to save the changes to the profile

If script execution is enabled, when you launch PowerShell it will automatically start with the configuration set in the profile file. If not enabled, proceed to the next section for information on enabling it.

This example only covers customizing the PowerShell console window. Keep in mind that any variables or functions you define in the profile file will be automatically available for use when you launch PowerShell.

This is it for today! Next week we’ll go into PowerShell scripting — so don’t miss the last article of taking command of Server 2008 with Windows PowerShell. See you next week!

Related posts:

• Take Command of Server 2008 with Windows PowerShell – Part 2
• Take Command of Server 2008 with Windows PowerShell – Part 1
• Take Command of Server 2008 with Windows PowerShell – Part 4

Welcome back! Today we’re learning about PowerShell Cmdlets and PowerShell Providers.

If you missed the first part of this short series, make sure to take a look at it when you get a chance.

Take Command of Server 2008 with Windows PowerShell – Part 1 will provide you with a good introduction to PowerShell and show you the steps to installing and accessing PowerShell on your Server 2008.

Now let’s get started with Cmdlets, the essence of Windows PowerShell.

Understanding PowerShell Cmdlets

Taking advantage of the power of PowerShell is done with the use of cmdlets. The cmdlets are powered by a set of .NET objects and methods developed with server and network administrative purposes in mind.

An example of a cmdlet is Get-ChildItem, which is used for listing the contents of an object. That’s right, object.

Any output created within PowerShell is output in the form of an object as opposed to text. An object is an item that can contain multiple properties and/or methods, which can return more objects.

If no action is performed on an object, PowerShell outputs the object details in text form. Actions can be performed on an object returned by a cmdlet by pipelining another command with the pipe character between commands.

The command below lists the contents of the current object (directory) sorted by name in descending order.

get-childitem | sort-object “Name” –descending

In the above example, the Sort-Object cmdlet is used on the return object of the Get-ChildItem cmdlet to sort by the Name property. Tacked onto the end of the command are the property and descending parameters.

The actions performed by cmdlets are determined by the parameters supplied to the cmdlet. Alternatively you could have supplied the –property parameter flag before “Name”, but because that is the cmdlet’s default parameter, that is not necessary.

Aside from the cmdlet specific parameters, you can also use common parameters with cmdlets to be handled by the PowerShell engine itself.

Not all cmdlets support all the common parameters; most of them usually work though. The common PowerShell parameters are defined below:

• -confirm – Prompts the user for confirmation before executing a command.
• -debug – Tells the cmdlet to provide debugging information.
• -ErrorAction – Allows the cmdlet to; continue, stop, silently continue or inquire when an error occurs.
• -ErrorVariable – Tells the cmdlet to assign error information to the variable specified.
• -OutBuffer – Tells the cmdlet to hold a certain number of objects before calling a pipelined cmdlet.
• -OutVariable – Tells the cmdlet to assign output to the variable specified.
• -verbose – Tells the cmdlet to provide more detail.
• -whatif – Tells the result of executing the command without executing it.

If you have been working along, you probably noticed that the output from the Get-ChildItem cmdlet looks a lot like what you would expect to see by entering dir. This is no coincidence.

When you enter dir you are actually entering the alias assigned to the Get-ChildItem cmdlet. Cmdlets come with pre-assigned aliases and can also have custom defined aliases.

Cmdlet aliases can be listed with the Get-Alias and set with the Set-Alias cmdlets.

Should you ever have the need to find out more information on a cmdlet you can use the Get-Help cmdlet. The Get-Help cmdlet itself has parameters such as –detailed and –full for determining the amount of help shown.

If you ever have trouble remembering the name of a cmdlet you can use the Get-Command cmdlet. Entering Get-Command by itself lists all the PowerShell cmdlets. You can also supply part of a cmdlet name to narrow down the results like in the example below:

get-command get-

Executing the above command lists all the cmdlets that begin with ‘get-‘. The Get-Help and Get-Command cmdlets should prove very useful for helping you to get familiar with the capabilities and usage of PowerShell.

Understanding PowerShell Providers

By default, when PowerShell is launched, you will start with your profile folder as your working directory. Access to this directory is available to you courtesy of the FileSystem provider.

PowerShell providers take the form of logical drives that provide access to data stored within the drives in a fashion that can be navigated and manipulated using the PowerShell cmdlets.

PowerShell comes packaged with seven default providers. You can list the available providers and their respective drives with the Get-PSProvider cmdlet. Additional providers can be installed with the New-PSDrive cmdlet.

The default PowerShell providers are explained below:

• Alias – Provides access to the aliases assigned to cmdlets.
• Certificate – Provides the ability to sign and work with scripts.
• Environment – Provides access to the Windows Environment variables that hold information on configuration and special folders.
• FileSystem – Provides access to the files and folders available on your local drives.
• Function – Provides access to the functions defined in PowerShell.
• Registry – Provides access to the Windows registry.
• Variable – Provides access to the variables assigned in PowerShell.

You can gain access to the different PowerShell providers by using the Set-Location cmdlet. The command below will change the working directory to the Variable provider.

set-location variable:

From the Variable provider you can list all the variables assigned in the console and their respective values with the Get-ChildItem cmdlet. You can also create new variables using the New-Item cmdlet or remove them with the Remove-Item cmdlet amongst other things.

It’s important to note that the Variable provider is not the only place you can work with variables. Variables can be assigned or used anywhere you go with PowerShell.

Variables are identified in the PowerShell console with the dollar sign. Executing the command below will assign a value to a variable.

$variable = “I’m a variable”

To display the newly assigned variable, execute the command below.

$variable

Providers give great potential for expanding the capabilities of PowerShell. They provide access for working with many resources on the server.

The PowerShell provider system has removed the restriction of working solely with the server’s file system within the command shell environment.

We’re done for today, but don’t forget to come back next week for more on taking command of Server 2008 with Windows PowerShell!

Related posts:

• Take Command of Server 2008 with Windows PowerShell – Part 1
• Take Command of Server 2008 with Windows PowerShell – Part 4
• Take Command of Server 2008 with Windows PowerShell – Part 3

The command shell evolved from direct entry into Windows underlying DOS environment to an emulated DOS Environment in later Windows versions.

All the while the command shell has made strides to maintain backward compatibility with the original DOS environment, however, little has been done to expand upon the capabilities of the command shell.

Utilizing the power of the .NET Framework, Microsoft has released a brand new command shell environment aptly titled Windows PowerShell.

Introducing: Windows PowerShell

Like its predecessors, Windows PowerShell supports all the previous command shell commands such as “cd” to change directories, and “dir” to list directory contents, and converting your old batch files to PowerShell scripts is virtually effortless.

But don’t be fooled by the fact that PowerShell can execute old commands and batch files. PowerShell is run by a brand new command set consisting of some 120 cmdlets.

Cmdlets make themselves useful within each of the PowerShell providers. Providers are objects that store their data in a structure navigable like the Windows File and directory system.

In fact, the default PowerShell provider is the FileSystem provider, which gives access to the files and folders stored on the system drives.

PowerShell’s automation and time saving capabilities become apparent when you take advantage of three key features.

• Pipelining command objects together
• Multiple commands separated by semicolons on a single line
• Powerful and flexible scripting engine

With all that, PowerShell not only acts as a replacement to the standard Windows Command Prompt, in many ways its usefulness as an administrative scripting engine exceeds that of VB Script. PowerShell scripting can accomplish virtually everything VB Script can and do it with greater efficiency in several areas.

Installing Windows PowerShell

Now that you have heard of this new tool, you are probably wondering how to get your hands on all that power?

Like most of Windows Server 2008’s useful features, Windows PowerShell is not installed as a default Windows Component. This is mostly because Windows PowerShell is dependent on .NET Framework 2.0 or higher being installed.

Assuming your installation of Server 2008 meets these requirements, PowerShell can be installed by following the steps below:

1. Open the Server Manager from Start | Control Panel | Administrative Tools | Server Manager
2. From the Server Manager Click Features then click Add Features
3. Check the box labeled Windows PowerShell and click the Next button
4. Click the Install button to confirm installation and wait
5. When the installation is complete, click the Close button to exit the Add Features Wizard

Accessing Windows PowerShell

With PowerShell now pleasantly residing on your server, all that is necessary to bring the power to your fingertips is launching it.

Like many Windows features, PowerShell can be accessed more ways than one. Below are the basic methods for accessing PowerShell.

• Start | Run | PowerShell.exe
• Start | All Programs | Windows PowerShell 1.0 | Windows PowerShell
• From the standard Command Prompt by entering PowerShell.exe

If you prefer, you could also copy the PowerShell shortcut from the start menu to the desktop or quick launch tool bar for easier access.

But Wait! There’s More …

That’s all for today, but don’t worry, in the next few weeks, you will have the opportunity to get fully acquainted with Windows PowerShell through a series of articles, this one being the first.

The main goal of this series is to show you the capabilities and proper usage of Windows PowerShell. So that after reading all the articles you will be familiar with the following:

• Installing and Accessing Windows PowerShell on Windows Server 2008.
• Launching the PowerShell command console.
• Executing cmdlets and working with the objects returned.
• Using the different PowerShell providers to work with server resources inaccessible from the FileSystem provider.
• Using variables to store and reuse objects in PowerShell.
• Customizing the user interface of PowerShell with the PowerShell profile.
• Taking advantage of the script engine to automate the performance of Administrative tasks on the Server.

Related posts:

• Take Command of Server 2008 with Windows PowerShell – Part 2
• Take Command of Server 2008 with Windows PowerShell – Part 3
• Take Command of Server 2008 with Windows PowerShell – Part 4