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

When you run Exchange Setup to prepare schema, usually the very next question is, how do I verify schema was updated successfully? Verifying only the values of attributes as mentioned below is not a good verification of Exchange setup completion. This article is intended to only provide reference to attributes and their values.

Let’s start back at Exchange 2003 SP2.

One of the last actions setup /forestprep in Exchange 2003 is to set objectVersion attribute on Exchange organization container to a value of 6903. You can verify this using ADSIEdit and navigating to Configuration NC, Exchange organization object under services\Microsoft Exchange node.

On the other hand, when setup /domainprep is run, it sets the objectVersion attribute on Microsoft Exchange System Objects container to a value of 6936. You can verify this using ADSIEdit and navigating to Domain NC, Microsoft Exchange System Objects container.

In Exchange 2007, after successful run of Setup /PrepareSchema you will find that the attributes mentioned above are not changed! You need to verify the value of rangeUpper attribute of ms-Exch-Schema-Version-Pt object in Schema NC. The value should be 10637.

It is only when you run Setup /PrepareAD the objectVersion attribute of Organization container in Configuration NC is updated to a value of 10666. You will also find that objectVersion attribute on Microsoft Exchange System Objects container in Domain NC is set to a value of 10628.

You will also notice that Setup /PrepareDomain does not have any effect on these attribute values.

Let’s briefly review what does Exchange 2007 SP1, SP2 and Exchange 2010 setup update these attribute values to.

Exchange 2007 SP1

• Value of rangeUpper attribute of ms-Exch-Schema-Version-Pt object in Schema NC is set to 11116 when setup /PrepareSchema is run successfully.
• Setup /PrepareAD sets the objectVersion attribute of Organization container in Configuration NC is updated to a value of 11221. objectVersion attribute on Microsoft Exchange System Objects container in Domain NC is also set to the same value of 11221.
• Setup /PrepareDomain does not have any effect on these attribute values.

Exchange 2007 SP2

• Value of rangeUpper attribute of ms-Exch-Schema-Version-Pt object in Schema NC is set to 14622 when setup /PrepareSchema is run successfully.
• Setup /PrepareAD sets objectVersion attribute of Organization container in Configuration NC to a value of 11222. objectVersion attribute on Microsoft Exchange System Objects container in Domain NC remains unchanged at value of 11221.
• Setup /PrepareDomain does not have any effect on these attribute values.

Exchange 2007 SP3

• Value of rangeUpper attribute of ms-Exch-Schema-Version-Pt object in Schema NC is set to 14625 when setup /PrepareSchema is run successfully.
• objectVersion attribute of Organization container in Configuration NC remains unchanged at a value of 11222. objectVersion attribute on Microsoft Exchange System Objects container in Domain NC remains unchanged at value of 11221.
• Setup /PrepareDomain does not have any effect on these attribute values.

Exchange 2010

• Value of rangeUpper attribute of ms-Exch-Schema-Version-Pt object in Schema NC is not changed from 14622 when setup /PrepareSchema is run successfully.
• Setup /PrepareAD sets objectVersion attribute of Organization container in Configuration NC to a value of 12640. objectVersion attribute on Microsoft Exchange System Objects container in Domain NC remains unchanged at value of 12639.
• Setup /PrepareDomain does not have any effect on these attribute values.

Exchange 2010 SP1

• Value of rangeUpper attribute of ms-Exch-Schema-Version-Pt object in Schema NC is not changed from 14726 when setup /PrepareSchema is run successfully.
• Setup /PrepareAD sets objectVersion attribute of Organization container in Configuration NC to a value of 13214. objectVersion attribute on Microsoft Exchange System Objects container in Domain NC is changed to value of 13040.
• Setup /PrepareDomain does not have any effect on these attribute values.

Exchange 2010 SP2

• Value of rangeUpper attribute of ms-Exch-Schema-Version-Pt object in Schema NC is changed to 14732 when setup /PrepareSchema is run successfully.
• Setup /PrepareAD sets objectVersion attribute of Organization container in Configuration NC to a value of 14247. objectVersion attribute on Microsoft Exchange System Objects container in Domain NC remains unchanged at value of 13040.
• Setup /PrepareDomain does not have any effect on these attribute values.

When reading this article, consider the fact that the lab setup I used was upgraded from Exchange 2003 schema to Exchange 2007 schema and then to Exchange 2010/SP1 schema. Service Pack 2 was tested in Exchange 2003 environment with no Exchange 2007 or Exchange 2010 Service Pack 1. This should not affect any attribute values mentioned above however I cannot guarantee since I have not tested it.

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

With it, comes new pre-requisites if you are installing/updating Client Access Server (CAS) role.

You will need to install the following components on the server that will be running CAS role (or existing CAS you are planning to update):

ISAPI Filters – Web-ISAPI-Filter
IIS 6 WMI Compatibility – Web-WMI
ASP.Net – Web-Asp-Net

You can install them as described in Exchange 2010 Prerequisites article. If you want to install these components on existing CAS server before upgrade to SP2, you can launch PowerShell as Administrator and then run:

Import-Module ServerManager
Add-WindowsFeature Web-ISAPI-Filter,Web-WMI,Web-Asp-Net

Note this post refers only to Windows 2008 R2. I haven’t checked if requirements are different for Windows 2008 (without R2) servers. They are, however, detailed in the TechNet articles linked above.

Enjoy!

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

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

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

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

While this is fairly documented on TechNet, it sometimes takes a bit to find and memory usually fails us when the question of precedence comes up. I figured documenting it here would help readers.

So the classic question of how to handle message size limits comes up very often and ever changing technology in pursuit of improvement never stays the same. This adds to the confusion of understanding the limits and the way they are applied across the organization. Also, it becomes challenging when you need to provide an exception.

Let’s take an example:

You have Exchange 2010 servers coexisting with Exchange 2003 servers. You have Maximum Recipient per message limit set to 5000 in Global Limits. You have the same set to 2500 in Organizational Limits.

A user comes up to you and presents a business need that requires him to be able to send a message to 3000 company employees at once.

Now this is an interesting scenario…

You can read the entire post 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

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

This is a great resource if you ever need to refer to network flow between different roles and well as different clients to server communications. This is too good of information to pass on without sharing.

I am sure you will benefit from it if you have anything to do with Exchange server.

Huge thanks to Michel for creating this very helpful document.

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

Here’s the link to his blog entry: http://www.stevieg.org/2010/11/comparison-outlook-2010-owa-2010-outlook-2011-features/

Thanks Steve for creating the comparison that will benefit many!

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