Exchange 2010 introduced RBAC as a mechanism to manage access to administrative tasks at granular level which was not possible in previous versions of Exchange.

While you may know how to use RBAC to create custom roles that maps to job functions in your environment, one particular feature tends to get easily overlooked, mostly because it is least understood I believe. It is Unscoped Top Level Management Roles.

So, I wrote a blog post on it detailing what it is, and how to configure it. It went live few days ago at Hey, Scripting Guy! blog.

You can read complete article here – http://blogs.technet.com/b/heyscriptingguy/archive/2012/01/13/use-powershell-and-rbac-to-control-access-to-exchange-server-cmdlets.aspx

Enjoy!

Originally posted at http://blogs.technet.com/bshukla

There is nothing new about this. If you have been reading about Exchange Server 2010 or have it deployed with hardware load balancer, chances are, you have read how to configure static ports on Exchange Server 2010 on TechNet Social wiki for Exchange 2010. Chances are that you have also used my script (referenced in the post above) to set static ports on your servers. Lastly, chances are that you have read all about it on my previous post here.

If so, why am I even talking about it today?

Well, if you haven’t noticed a few things already, the way you change ports is different in RTM and SP1. My script didn’t account for SP1 originally when it was written. Was SP1 even existed then?

The other reason is my nature of always learning something and making things better! I noticed how my code was inefficient now that I know a few more things about PowerShell (yeah that’s not funny). I decided to write it more efficiently and that basically meant a complete overhaul of my old script.

The new script is now more user friendly! It uses cmdletbinding and comment based help. It means, for you as a user, you can just type:

Get-Help Set-StaticPorts.ps1 –examples

or

Get-Help Set-StaticPorts.ps1 –Full

The script now validates parameters using ValidateRange and ValidateScript. I think that’s cool! It also uses 59531 and 59532 by default now. How about using recommended ports instead of random ones I used in my previous script? I think that’s even more cool!

The script uses all the right write-* cmdlets now instead of write-host. So now you can use tee-object and won’t end up with empty output file. Yes you loose cool colors I used with write-host but hey, you are trying to set ports on your Exchange Server 2010. For colors you would go see Macy’s Fireworks on New Year, right?

Oh and last but probably the most important change is inclusion of –auto and –whatif functionality!

-WhatIf is obvious. Script will tell you what it is doing without actually making any changes.

-Auto will automatically find all your Exchange 2010 CAS servers and Exchange 2010 Mailbox servers that are hosting Public Folders. It will then change ports on CAS Server for RPC CA service and Exchange AB service. On Mailbox servers it will only change RPC CA ports as Exchange AB service doesn’t exist on Mailbox only role.

If you combine all this with –Force, you can also silence the script. It won’t ask you for any confirmation and will change ports you specify (or use defaults) and restart the services! Isn’t that awesome!

So go download the script from here: Set-StaticPorts.ps1 and give it a go. As always, let me know if you find any issues and I will be happy to fix it.

Originally posted at http://blogs.technet.com/bshukla

A misconception that WinRM listener needs to be configured in order to be able to connect to Exchange Server 2010 had popped up a couple times in my conversations recently so I decided to clear the confusion. Guest blogging for my friends at IT Pro Africa, I have written the details on the blog post here: http://itproafrica.com/technology/exchange/exchange-server-2010-and-powershell-remoting/

Check it out and feel free to post comments either there or directly here.

Originally posted at http://blogs.technet.com/bshukla

Disclaimer: I am not paid to write about this book and the review written here is my own view.

I was recently contacted by Packt Publishing about their recently published book “Microsoft Exchange 2010 PowerShell Cookbook”. I have voluntarily reviewed books in the past (i.e. Windows Server 2003 Security: A Technical Reference by Roberta Bragg) out of my interest and curiosity. Same interest and curiosity lead me to accept the request and spend some time reading it. I am glad I did because I did find a few interesting things which while I may have known, have never tried to script either because there was no need to do so or was never asked to do so.

I figured posting the review here would give potential readers one more data point to take into their consideration. I am sure the book will benefit any reader working with Exchange Server 2010 and wants to expand on their PowerShell knowledge as it relates to Exchange Server 2010.

Without further due, here it is:

The Premise

Mike Pfeiffer is well known for his contributions to Microsoft Exchange community which has also earned him Microsoft MVP award.

Keeping him in check are the reviewers like Shey Levy, which only means one thing: it is going to be tough for Mike to make a mistake and have it go unnoticed into the book for publication.

Microsoft Exchange 2010 PowerShell Cookbook promises to show you how to automate routine tasks and solve common problems. The book is organized in logical sections walking the reader through key concepts and tasks to manage their Microsoft Exchange 2010 environment with ease.

While the book focuses on on-premise deployment of Microsoft Exchange 2010, the concepts covered should make reader comfortable in managing their Office 365 tenant.

The Content

The book dives into Exchange 2010 management tasks by starting on the right foot. While most of Exchange administrators would be familiar with PowerShell in some capacity, authors don’t just assume and start off with PowerShell key concepts. This is really helpful to novice readers just as much as experienced PowerShell users who may learn a thing or two they didn’t know before.

The book covers every aspect of Exchange 2010 management including recipient management, Database and Server roles management, High availability, Compliance and RBAC.

The book also covers scripting Exchange Web Services which was a pleasant surprise as writing scripts for EWS is difficult only due to lack of understanding on the subject. EWS API and scripting details in this book tries to address just that.

Each section is organized into different tasks reader may want to perform. The tasks have a good flow of precondition, how to perform given task and details explaining what the given cmdlet is doing or information on actual process being followed. There are also very useful tidbits in “There’s More…” sections at end of each task being performed. This will help reader not only understand the task at hand but to leverage the information to carry out other tasks that may be related but not explicitly written about in the book.

Summary

Overall Microsoft Exchange 2010 PowerShell Cookbook is a welcome addition to what’s already been written about Exchange 2010 or PowerShell. While the book doesn’t teach you Exchange 2010, it does a great job of educating the reader about PowerShell and how to get the most out of Exchange 2010 using PowerShell to manage it.

Originally posted at http://blogs.technet.com/bshukla

I ran into an interesting discussion with my customer today.  He was writing a code block that looked like the following:

Try {
Get-MailboxServer Bogus
}
Catch {
"Mailbox server doesn't exist"
}

Looking at the code, it’s very simple. Run a command in try block and if error is generated, report on it using catch. However, it didn’t work as it should. That’s why it became interesting.

I tried the following:

Try {
somestring
}
Catch {
"Error"
}

Now that worked just as you would expect!

What was going on here. I was puzzled and so was the engineer who asked me about the error in first place. So we looked at the about_Try_Catch_Finally on TechNet. As an IT Pro would usually RTFM, we went straight to examples and that looked just like our problem child. No issues when we run that example but when we run our code, it doesn’t want to work.

Again, as any other IT Pro would do, we did the next “logical” thing to match the example code with ours and decided we weren’t specifying error type. While we both agreed that it wasn’t the case, we still wanted to make sure. So we looked at the error object:

$Error[0].Exception.gettype()

IsPublic IsSerial Name                                     BaseType
-------- -------- ----                                     --------
True     True     RemoteException                          System.Management.Automation.RuntimeException

Then we changed out Catch statement to specify the error type. That, as you may have guess it by now, didn’t work either!

This is actually when we started paying attention to TFM. If we ever read the description on the TechNet documentation, it reads “Describes how to use the Try, Catch, and Finally blocks to handle terminating errors.”

So very clearly, it says the error must be a terminating error. And the errors we were generating when executing Get-MailboxServer cmdlet, were not terminating errors! As they say it all the time, once you find the issue, fix takes only seconds. All we had to do at this point was to make the error a terminating error:

Try {
Get-MailboxServer Bogus -ErrorAction Stop
}
Catch {
"Mailbox server doesn't exist"
}

And the world was fine once again.

Originally posted at http://blogs.technet.com/bshukla