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

I had custom script that would modify certain registry entry but it was inflexible and in my recent rewrite of another script, I wanted more flexibility. So out of necessity, I decided to rewrite my registry script  and made it independent script with lot of flexibility.

Using this script, you can now run it like this:

.\Set-RemoteRegistry.ps1 -Key SYSTEM\CurrentControlSet\services\AudioSrv\Parameters -Name ServiceDllUnloadOnStop -Value 1 -Type DWord

If you want to suppress prompts, you can use –Force parameter like this:

.\Set-RemoteRegistry.ps1 -Key SYSTEM\CurrentControlSet\services\AudioSrv\Parameters -Name ServiceDllUnloadOnStop -Value 0 -Type DWord –Force

This script is also a good example of cmdletbinding and support of whatif. I still think use of Whatif in scripts has its limitations as apprarent in this script (without adding more code to it to work around that limitation).

The script is also a good example of how you can use parameter validation right in the parameter declaration. This way you can avoid if..then code blocks to validate parameter inputs. What a wonderful discovery, I gotta thank PowerShell team for this.

So go ahead, get the script Set-RemoteRegistry.ps1 here and if you find any issues, let me know. Have Fun!

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 driving him around town on errands, as I usually do, I was listening to the public radio broadcast on WHYY. While it was good conversation, it was more or less a blur to my grown up brain and while sobering, it wasn’t heartfelt. But to my 5 yr. old it was a lot more. I sensed that as soon as he started asking endless questions. All very innocent, all very touching. He asked me what memory meant when he heard “sonic memorial” on radio. He asked me why they won’t build two towers now. And when I ignorantly I said I don’t know, he said because they have built a fountain there. That’s when it struck me how ignorant I was. While he was listening to same radio and watching same news on TV as I was, he was actually the one paying attention!

What touched me the most is when he said when he grows up, he wants to start a company in L.A. (not sure why he picked that) and will build twin towers everywhere except in New York city because they have fountain there! It send a shockwave through me. How a kid, who has no idea of the magnitude of the events that unfolded on that unforgettable morning, wanted to do so much for a memory!

That’s when I woke up and decided create a picture to tell the story.

I am not an artist so I have used pictures I came across from image search on search engines and if I am violating any copyrights unknowingly, I hope the authors will understand that I have no intention of making this image available for sale. I just want to do this for my child and his endless curiosity. God bless him.

What I am sharing here are some outcomes of my numerous attempts with two formats; one for desktop wallpaper and one for print (8×10 format). Feel free to download for personal use. Please do not try to sell out of respect for the victims. I claim no copyright to these photographs. If I have used your photograph and you don’t want me to use it for this good cause, let me know and I will immediately remove it.

		Remembering Sept 11 VIEW SLIDE SHOW DOWNLOAD ALL

Oh and if you want to know how did I create this collage, check out Microsoft Research AutoCollage.

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