New Administration Functionality in the Exchange Management Console

New Administration Functionality in the Exchange Mangement Shell

New Exchange Concepts and Definitions

New Unified Messaging Functionality

New Client Functionality

New Messaging Policy and Compliance Features

New Anti-Spam and Antivirus Functionality

New Antivirus and Anti-spam Products for Exchange 2007

New Transport and Routing Functionality

New Performance and Scalability Functionality

New High Availability and Clustering Functionality

New Exchange Database Functionality

New Information Worker Functionality

New Deployment Functionality

New Development Functionality

You can click here for  a summary information about each of these subjects:

Exchange Management Console
Exchange Management Shell
Unified Messaging
Performance Improvements
Availability
High Availability for Mailbox Servers
Messaging Policy and Compliance Features
Security and Protection
Autodiscover
Extensibility and Programability

Without giving away any of Bruce’s secrets, (which are worth reading for yourself) he clearly explains the use of the Cmdlets and concepts needed to program with PowerShell. His discussions are clear and very thorough with a smattering of well done code examples. I’m looking forward to the heavier topics in the later chapters. One side note, it’s a great book to start with, but if you already have some scripting or programming knowledge it will be a little easier. Newbie’s beware that he goes pretty deep fast.

So, why is PowerShell a living “Hell”? Well, I really want to get as deep as possible with this, as I see it becoming one of the most powerful administration tools we have. Bruce’s book highlighted the glaring fact that I needed to brush up on my programming skills. So, I’m spending this week in one of our 4152 Core C# classes to get my programming skills ironed out. It’s been a few years since I have had to do the “real” coding stuff, so I need the refresher.

The interesting thing (and Bruce mentions this in his book) the amazing similarities that PowerShell and C# have (you will also notice the Python similarities). In fact, PowerShell can be written in a very terse manner, or it can follow almost an identical C# form. Here’s a little example defining a variable and setting a value.

PS: (short version) $myVar = “abc”

C#: string myVar = “abc”;

PS: (Long version) [string] $myVar = “abc”;

PowerShell even takes the “;”!! This has caused some internal debate here at InterfaceTT. When we create a training course for PowerShell, should we teach it using the long version or the short? The short is fast, easy, and simple to remember, but the long version has its pluses too. One of the biggest pluses is that if students learn the long version, they can easily use the official C# language as well. The syntax conventions are close enough that changing between the two would be much easier. If you want to create your own Cmdlets, you will need the C# skills anyways. So that’s one of my questions, what do scripting engineers think they want to do? Will they want to learn enough to handle C#?

To further the argument, there are several language specifics that are virtually identical to begin with such as the “for” loop.

C#: for (int i = 0; i < 10; i++) {…}

PS: for (int i = 0; i -lt 10; i++) {…}

If you look close, you’ll notice in the condition, the second statement uses a unique style of comparison operator. Bruce Payette discusses this in his book. They didn’t want to use the traditional (<,>) style operators because PowerShell is a shell, and the <,> characters are used for redirection. Instead, they opted to use the UNIX standard for the new shell. I must say, that after spending sometime working with PowerShell/Monad, I agree with their decision. It actually makes since, and they included comparison operators that will test for case sensitivity or non-case sensitivity such as –ilt (non-case sensitive less-than) –clt(case-sensitive less-than) –lt(uses non-case sensitive less than as a default)

Then there are the screaming differences between the two languages. Look at this example of creating an Array in C# and PowerShell. Both examples create a three element string array and stores three names.

C#: string[] myVar = new string[3] { "Jason", "Spike", "Simon" };

PS: $myVar=(“Jason”, “Spike”, “Simon”)

Now, remember, I’m a newbie to this stuff too, so I’m sure there is a way to make it more C# like, but WOW what a difference. Now, I’m a System guy, so I choose the PS way over the more complex developer way.

These are the kind of language challenges that I’m debating on how to handle in a full PowerShell course. Which is best to learn? Is there advantages to learning it the C# way? What do you guys think?

An additional challenge that I’m trying to work out is that PowerShell is an Object-based language, not an Object-oriented one. Is this just semantics? Well, no, its not. In PowerShell I can use or instantiate objects that have been built for me, such as from the .NET Framework, but I can’t actually create my own. (BTW PowerShell is not JIT compiled either, pretty much an interpreted language). I have a lot of questions about this. Can I create classes in C#, strongly name them, put them in the GAC and then instantiate them from PowerShell? Will PowerShell ever allow me to create classes? If so, will it be JIT compiled, and become an official object-oriented language and a .NET language? Will System administrators need these skills? Will they actually need any OOP (Object Oriented Programming) skills?

I love this 4152 class, Jennifer has been doing a great job and it has helped me get my skills back into shape. It would be nice if the Visual Studio Team would Add PowerShell scripting to the VS IDE. Hey Microsoft! How about a little help with that! For now I’ll stick too using Sapien’s Primal Script 4.1 as my IDE.

That’s putting the hell into PowerShell for me right now. Lots of questions, very few answers. But I really love what the PowerShell guys at Microsoft have done. I still have a lot of work to do and a lot of learning to do to catch up. Now I’m moving on to scripting some solutions for my network. I’ll share how it goes with you.

Now the book is not available yet in print, but they are letting everyone download load it under their MEAP program.  I have no idea what the MEAP program is, but for $22 I got to download and print the book. 

I hate reading, but this looks good.  Those of you that know me know I hate boring Authors and crappy books, and I have no problem slamming garbage in the trash can, but the first few pages I've read give me hope that this might be just what I needed.  I'll post my review after I finish it, probably after ThanksGiving.  It seems to be loaded with examples, and apears to be much deeper than the O'Reilly book "Monad".  The "Monad" book was a good intro, but certainly not good enouph to start really getting much work done.  This one looks to be much more indepth, which makes since now that there is a release product.

Anyway, if your bored and without beer this holiday, you might want to spend the $22 bucks and take a look for yourself.  The website is http://www.manning.com/payette/

Have fun!

What are video-blogs?  Well, when I'm lonely and sitting in the dark at home, I love to watch the webcasts that the scripting guys have at www.scriptingguys.com.  I was sitting back last Friday watching the webcasts on PowerShell that they just published from the PowerShell week, again with beer and sitting in the dark, when an idea popped into my head.  "Why, by George (I don't know who George is but....) I think I'll make a webcast about my experiences with PowerShell!"  This seemed to be a wonderful idea, so I preceded to make a few webcasts if your interested.

First I did one to help everyone get it downloaded and installed called "Installing PowerShell".  Its a great place to start. 

The second one I did is based on my love of PrimalScript by Sapien.  They just released there new version 4.1 and it includes everything you need for Powershell.

Well, things were going just great.....I had gotten PowerShell to install, ran a few cmdlet's and life was good.  I went out to the script repository on the scripting guys website and snagged a few scripts to test PowerShell, when suddenly I was horrified.  Thats right boy's and girls, I was horrified.  I guess the good folks at Microsoft decided to build in security to PowerShell.  The kind of really hard security that prevents hackers from sending me malicious scripts like they did with VBScript.  Half wasted and running out of beer, I had to find a solution fast........well.........The third video-blog shows you how to change the security policy so you can start running your scripts.

Let me know if they were helpful, or if you have any ideas for other video-blogs.  I'm going to make some more on using cmdlets and on the new scripting language.  I'll let you know if I find anything cool.

Since its almost "Turkey" day, I'm sure I will find myself again lonely, in the dark, and with beer, working on PowerShell, so I'll make some more video-blogs.

P.S.  Not beholden to the man.  sir..

There might be a little “programmer” in us all...

I hate vaporware.  I hate talking about vaporware.  I hate the marketing departments that think we care about vaporware.  I REALLY hate the nuggets of publicity about vaporware, along with the long string of adjectives that tell me how it’s going to change my life.  One more string of “new, latest-and-greatest, really-cool, awesome, make-your-job-easier, less-downtime, more-control, reliability, flexibility, availability, manageability, ability this, ability that, STOP!  We are approaching one of the largest (if not largest) product release cycles in Microsoft’s history and the media is loaded with noise about our futures. 
Remember the “Nobody will ever need more than 640k RAM” quote?  If one of the smartest people to walk the earth can’t forecast the future, than how is a group of neophyte marketing boobs going to save my career, get me a Porsche, and 50 days of vacation a year. 

Well, in a nutshell, I’m wrong.  It isn’t the first time, nor will it be the last, but I’m horrible wrong.  About the whole thing. 

I’ve been reminded that “old” might be the “tried and true”, but “new” is not necessarily “bleeding technology” or “hype”.  There is this new creature looming on our future that is, well, one of the newest, latest-and-greatest, really-cool, awesome, make-your-job-easier, less-downtime, more-control, reliability, flexibility, availability, manageability, etc. technologies available.  If you’re managing a network, you can’t miss this, I really mean it……stop and smell the “Monad”

I’m always looking for better ways to manage a network.  For years I have been a huge fan of the “scriptcenter” on Microsoft’s website.  The amount of work that Dr. Scripto and the guys (sorry, gals too) have put into finding ways to better manage a network through scripting is truly incredible.  Its not only one of the most helpful web sites, it’s also one of the funniest.  Yea, you read that correctly, it’s funny and educational.  In fact, it’s my favorite place to go.(no really, it is, but I also don’t have much of a life.)

I first started scripting (many moons ago, in a land far, far away) when I needed to collect a simple computer inventory for a customer.  I could have tried to get them to use SMS, but they didn’t need SMS, they just needed an inventory.  I sat down and started to figure out how to write a script and use WMI to perform the task for me.  My first challenge was learning the VBScript language.  I probably should have learned Jscript, but I chose the easier language to learn.  It worked, and worked well over the years.  Using HTML, I started making .HTA’s, little applications that looked like a web app, but could also run WMI.  It was great, but rather limited.  Microsoft, and the script-guys really opened up a whole new world of possibilities, but I really wanted a more powerful language.  Also, VBS is a dead language, especially now with VB.NET and C#.NET.(Veni, vidi, vici)  I’m sure the folks at Microsoft would disagree, but I just couldn’t get away from singing funeral dirges every time I opened up notepad to write another script.  I watched my UNIX buddies managing UNIX and Linux servers all over the place, and they could do everything from a “shell”, and they could do it fast, amazingly fast.  Hey!  I’m a Windows guy, how do I get one of those neat “shell” thingies (What my UNIX friends lacked in personality they made up for in incredibly useful tools and ideas)

Anyway, I’ve been teaching other Engineers over the years how to script for Windows.  Most of them have never programmed anything in their life much beyond a batch file, so using VBS as the language made life easier for them.  They could learn it quickly, solve some business problems, and go into the future with VBS reference books in hand.

But VBS is a security problem, limited in functionality, not capable of accessing the .NET Framework, not command-line driven, and on and on it goes.  Sure, it’s easy to learn, but what you have at the end of the day is still a marginally functional script written in a dead language.  Wouldn’t it be nice to have something as powerful as one of the premier development languages, and so feature-laden it would make a UNIX administrator start using Windows?  Welcome to the Microsoft Windows PowerShell.

Formerly code named “Monad”, the PowerShell is getting ready for release.  It’s currently planned (vaporware warning…..this might change) to be included with Exchange 12 and MOM, but will also be available for Vista/Longhorn, Windows Server 2003 and Windows XP.  It’s currently available as a download from Microsoft in its RC1 release and works very well on Windows Server 2003 and XP. 

The PowerShell is instantly familiar to those UNIX and Linux gurus.  It uses a C-based language for the shell and the scripts.  It almost smells a little too much like UNIX, but that is actually a good thing.  Nobody knows better how to manage thousands of computers through a script than UNIX folks do.  The challenge in using Windows PowerShell is also its greatest feature; it’s C-based.  This makes learning the language a little tougher but it’s worth the pain for the gain.  I’ve talked to a few Engineers (non-developers) that are struggling with the PowerShell.  It seems that everyone that touches it, loves it, except for the learning curve to use it.  I found it difficult to change from my old VBS to the new language.  In fact it can be so confusing to work with both languages that I wonder if you haven’t learned Windows Scripting yet, you would probably be best not to even bother with VBS and focus all your strength on PowerShell. 

Unlike the VBS language, the PowerShell provides access to the .NET framework, all of the amazing WMI functionality, in-line programming and scripting, piping and more.  If you find yourself truly enjoying the programming, moving from PowerShell to the vaunted C# language will be a natural progression.

Now, from my view, there are still a lot of un-answered questions yet.  Will the PowerShell give you all the same access to Active Directory and WMI as you had before?  It’s supposed too, but I haven’t tried everything yet.  Will there still be a simple way to make cute little .HTA applications or something similar?  I don’t know if that’s possible, but I’m hoping.  There are very few reference scripts on the scriptcenter as of this date.  No big deal, half the fun for me is converting the VBS scripts to PowerShell, but that means I still need my VBS skills. 

There are still so many open questions about the PowerShell that it’s hard to see how the future will unfold, but one thing is clear, the PowerShell will be a huge part of it. 

Go to the scriptcenter and check out the latest information on PowerShell and download the RC1 release.  I’m starting to develop a new classroom course on scripting with the PowerShell, so over the next few months I’ll post pictures and cool things you can do. (Or can’t do as the case may be) 
Keep a close eye on those scripting guys at Microsoft.  They’re funnier than I am anyway.