Leaving Microsoft isn’t a decision you can make easily. Working for such a company is a privilege. Working with such an amazing talent everyday is something to die for. Working to produce, deploy and support such amazing products is something to be proud of.

So, why am I leaving?

I have been working on design/deploy/manage/support numerous technologies since I started my career about 17 years ago. While in different flavors, I kept eating the same ice-cream. Not that I don’t like ice-cream. I totally LOVE it.

However, it is time for me to do something else. Something different and new. Something that I wasn’t planning for. Something I didn’t think of actively. But pleasant accidents are part of my life. Becoming IT Pro when by education I am a civil engineer was by accident, not planning. Leaving my home in India to face huge unknown and a new culture in US, wasn’t planned but happened in sudden succession of chain of events, pleasant accident and no planning!

And now this. This new role that came along. New role that is taking me into a huge unknown. New challenges that will take me completely out of my comfort zone. And I was taught in my first week at Microsoft that in order to grow, you must look for challenges that take you out of your comfort zone. I guess I took it to heart!

Microsoft has taught me a lot, given me a lot, cared for me a lot and that will never be forgotten. Leaving such a company earns me a label of defector, traitor and all fun names you can call it. However, I have yet to find one person in Microsoft who actually was serious when they said that. Everyone wished me well, offered to stay in touch and reach out if I ever needed their assistance or help. That’s the spirit of Microsoft.

So, where am I going? Clearly, I wish not to announce that here, however, I would say, unlike popular belief that most Microsoft employees leave for major competitors, or start their own business, for me, it’s not the case. I am going to work for a small company that is my type. Young, energetic, agile. They have a good product that has huge potential. The product that I am hoping that in my role I will be able to make even more AWESOME. Even more successful. Even more respected.

Next question you may have is if I am going to continue working on my passion, Exchange and Lync. The answer is yes! I will continue my lifelong learning of such amazing products and will continue to contribute to community through my personal blog https://www.bhargavs.com as well as the User Group I started few years ago in Philadelphia area: https://www.phillyexug.org. I will continue delivering training at MCM Exchange rotations. And since I am also a certified trainer (MCT), you may see me delivering MOC training sporadically.

So, if you want to keep in touch, I invite you to follow my random thoughts at my IT playground https://www.bhargavs.com, connect with me on twitter @bhargavs and linked in at https://www.linkedin.com/in/bhargavshukla.

I thank you for amazing readership through these years and I hope I was helpful in some meaningful way, or entertaining at the least. I wish you well and hope to see you around. Cheers.

After a long period of laziness and ignorance of my home network, I finally got tired of buffering issues when I stream HD videos I took on vacation and decided to do something about it. I setup Linksys WRVS400N knowing all my devices do support Wireless N including my XBOX360 where I will be watching those videos.

Since I can do Wireless N on all my devices, I decided to setup wireless as N-Only instead of mixed B/G/N. Once router was configured, I started with my laptop running Windows 8. As usual, it saw the new network, asked me for password and I thought that was it. Rarely it is though, isn't it? To my surprise, it could not connect to wireless. My Intel Centrino Ultimate-N 6300 AGN was perfectly capable of connecting to N, so why wouldn't it?

So I switched the router to G/N mixed mode and the laptop connected immediately. It certainly was something with Wireless N, but what was it?

After a bit of research, I found out that The IEEE 802.11n Draft prohibits using High Throughput with WEP or TKIP as the unicast cipher. While I was not using WEP (I had configured WPA security), I did happen to have TKIP as my cipher on WPA! I was now staring at the answer to my problem.

As they say, fix is 2 seconds once you find the cause of the problem. It took more than an hour to find the cause but once I did, it took me 2 seconds to switch my settings to WPA2+AES and all of my devices successfully connected!

Now on to my vacation videos… cheers. J

Until today, my favorite feature was Get-Help's –online parameter. For the cmdlet that have specified online uri of help topic, get-help cmdlet –online takes you straight to cmdlet help page in your browser, given you have internet connectivity on the machine you are running the cmdlet.

That was until today. Today, I was running get-help cmdlet on one of new servers I just built and looking for help, I typed Get-Help and this is what I got:

Do you want to run Update-Help?
The Update-Help cmdlet downloads the newest Help files for Windows PowerShell modules and installs them on your
computer. For more details, see the help topic at https://go.microsoft.com/fwlink/?LinkId=210614.
[Y] Yes  [N] No  [S] Suspend  [?] Help (default is "Y"):

Who in their right mind would say no? J

Once I pressed enter, PowerShell happily connected online and downloaded updated help files for each module available and then applied it. It then continued to show me updated help for the cmdlet I asked it for.

I am sure this is going to be short lived favorite as I discover more. What will stay with me is new cmdlet… Update-Help. Cheers.

UPDATE: Please read updated guidance due to changes introduced in SP2 RU4 here: https://blogs.technet.com/b/exchange/archive/2012/08/14/calendar-and-tasks-retention-tag-support-in-exchange-2010-sp2-ru4.aspx. It specifically addresses Calendar items and tasks.

I wouldn’t be talking about it today!

When the topic came up with my colleague, it quickly became a confusing discussion of what’s what, what works, what doesn’t and why TechNet seems to say something that doesn’t work.

So let’s start with this article: “How Retention Age is Calculated”. This clearly states how age is calculated on Calendar items, Tasks, Contacts and other items. Then it immediately mentions in the Note that retention tags aren’t supported for the Calendar and Tasks. The Managed Folder Assistant doesn’t process items in these folders.

This is really what is a start of confusion. The article “Understanding Retention Tags and Retention Policies” doesn’t mention the same fact (probably to avoid duplication).

The confusion is evident when Bharat specifically spells out in EHLO article “Prevent archiving of items in a default folder in Exchange 2010” that Calendar, Tasks and Contacts folders aren't supported.

However, above all, the confusion prevails! So let’s clear things up a little bit.

Exchange 2007 feature Managed Folder Policies, aka MRM 1.0 functionality supports Calendars, Tasks etc. However, it has its limitations. MRM 2.0 functionality provides more flexibility so individual folders can have different retention either applied to mailboxes using policy or by user using tags on folders or messages individually. Not to mention, at the cost of being able to process Calendar and Tasks along with Notes and Contacts. In SP1, Notes are processed, however, don’t expect more than that!

So if you want to process Calendar items, Tasks or Contacts, you should use Managed Folders. It does mean you won’t be able to apply one policy to one folder (i.e. Inbox) and different policy to another (i.e. Calendar). It also means that you can’t archive enable the mailbox that has Managed Folders policy applied or you can’t apply Managed Folders Policy to mailbox that has archive mailbox. If that is clear, I assume you know by now that Managed Folder Policy can’t move anything to archive mailbox. Although, never assume, so previous statement should remove my assumption and clearly tell you what it is!

Conversely, if you apply Default Policy Tags or Retention Policy Tags to a mailbox, Managed Folder Assistant will not process unsupported items. Namely, Calendar, Tasks, Contacts and Notes in Exchange 2010 RTM and Calendar, Tasks and Contacts in Exchange 2010 SP1.

Also worth noting is that you can either apply Managed Folders Policy or Retention Policy Tags (DPT/RPT whatever you call it) but not both to a mailbox. You can apply Managed Folders Policy to one mailbox and Retention Policy Tags to another in same Exchange 2010 database as these settings are per mailbox.

Oh and that “How Retention Age is Calculated” post isn’t incorrect. It correctly states how the age is calculated. Just understand it only applies to Managed Folder Policy.

Clear a mud? Perfect!

When you launch Exchange Management Shell or try to connect to an Exchange 2010 Server remotely using PowerShell, you get error “500 – Internal Server Error. There is a problem with the resource you are looking for, and it cannot be displayed.”

Error details also show the following:

For more information, see the about_Remote_Troubleshooting Help topic.

    + CategoryInfo          : OpenError: (System.Manageme....RemoteRunspace:RemoteRunspace) [], PSRemotingTransportException

    + FullyQualifiedErrorId : PSSessionOpenFailed

The other possible errors you may see are the following:

The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic.

Or

Connecting to remote server failed with the following error message: The WinRM client received an HTTP server error status (500), but the remote service did not include any other information about the cause of the failure. For more information, see the about_Remote_Troubleshooting Help topic. It was running the command 'Discover-ExchangeServer -UseWIA $true -SuppressError $true'.

Or

The WinRM client received an HTTP status code of 403 from the remote WS-Management service.

All of these issues relate to a problem with PowerShell virtual directory on given server not configured properly. If you were to run Exchange Best Practices Analyzer, it alerts about this issues as well.

The resolution is well documented on TechNet article “PowerShell Virtual Directory issues cause problems with Exchange Management tools”. I will let you read the solution there, however, I wanted to mention the oddity in my case.

Looking at the error I was getting and mapping it to solution in article didn’t resolve the issue. I had to configure kerberos authentication as mentioned in the article. Once KerbAuth was registered as native module, EMS and remote PowerShell sessions started working.

What my friend mentioned seems so relevant: “Why can’t our lives be just as predictable as computers? While there are some problems in a day, most of it is logical and if you know that logic, you can predict the outcome or fix the issue!”. Amen to that my friend.

Everything looked good except certificate that we imported. The certificate looked good when looking at validity, issuing authority certificate and other dependencies. However, Exchange Management Console complained:

“The certificate status could not be determined because the revocation checked failed.”

Since the error seemed clear enough, we checked and verified that we can reach CRL. We could successfully access it and download CRL. We also ensured that there was no proxy servers configured or required, which they weren’t.

However, the server had its own mind.

KB979694 wasn’t applicable since there was no proxy in the environment.

The only logical thinking here was, why is “Local System” account (which the service uses to get the revocation status) unable to get to CRL. To get to the answer, we needed to check proxy settings of Local System account. How do you do that? You can’t simply start IE as different user!

That exactly is the purpose of this post. I found bits and pieces of information that helped me resolve the issue but not a one step document. In this post, I am trying to put it all together so you have one stop solution.

Here’s how you can fix the issue:

1. Open up command prompt as Administrator
2. Run “sc create testsvc binpath= "cmd /K start" type= own type= interact”
• This creates testsvc service which will run as local system and allow interaction with desktop
3. Run “sc start testsvc”
• The error “[SC] StartService failed 1053” is expected and can be ignored safely
4. Locate “Interactive Services Detection” icon blinking in the taskbar and click “view message”
5. You are now in a command prompt window running as Local System and you will not see your desktop. The only other visible window is “Interactive Services Detection” window.
6. Launch Internet Explorer using the following command:
• "c:\Program Files (x86)\Internet Explorer\iexplore.exe"
7. Internet Explorer may present Set up window. If it does, click “Ask me later”.
8. We will now check proxy settings. Go to Tools -> Internet options -> Connections -> Lan Settings.
9. Verify proxy and automatic configuration options and change them to match your environment. In my case we cleared all checkboxes since no proxy existed in environment.
• In our case, either server build process or a setting from or a GPO was populating incorrect proxy settings.
10. Close Internet Explorer window and return to command prompt.
11. We will now clean certutil caches.
12. Run “certutil -urlcache ocsp delete”
13. Run “certutil -urlcache crl delete”
14. We’re almost done here. We now have to close and exit out of service.
15. Type “exit” and press enter to close command prompt that is running as Local System.
16. Now you should have only one “Interactive Services Detection” window.
17. Click “Return Now”.

You are now back to your desktop and we have corrected Internet Explorer settings for Local System (removing proxy configuration that was incorrect). After this, we restarted Exchange Management Console and verified certificate on CAS server in question. Certificate was no longer issuing the warning and we proceeded with assigning the certificate to appropriate services.

It is important to note that refresh time varies from immediate to more than few minutes so don’t fret over certificate still showing the same error. If, however, it takes more than 15 minutes, I would check if all steps were followed as mentioned above and configuration is correct for your environment.

Yet another issue put to bed. On to another.

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 - https://blogs.technet.com/b/heyscriptingguy/archive/2012/01/13/use-powershell-and-rbac-to-control-access-to-exchange-server-cmdlets.aspx

Enjoy!

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.

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!

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.