Cmdlet extension agents are new components in Exchange 2010 that are called by Exchange 2010 cmdlets, when they are run. It is used to extend the functionality of Exchange 2010 cmdlets by running a script or set of code after the Exchange cmdlet has run. For example, you can run a set of configurations after a new mailbox has been created, basically calling the scripting agent to run a code after the New-Mailbox cmdlet completes. Scripting agent is one of the seven cmdlet extension agents available in Exchange 2010 and is the one that is disabled by default.

Get-CmdletExtensionAgent will list all the seven agents. Run Get-CmdletExtensionAgent | ft name, priority, enabled –wrap –autosize to get a refined output.

I looked at the scripting agent as one of my client asked me ways to automate things to a certain extend. I will explain the process of using the scripting agent based on what I had been asked. My client wanted to make sure that all newly created mailboxes had the following configurations, without manually setting each.

• POP, IMAP, ActiveSync is disabled
• Outlook Anywhere is disabled
• Single Item Recovery is enabled
• Fields like Country, City, Street Address, Company in the user properties needs to be filled in automatically.
• Block users from using Outlook in online mode
• Set the company OWA Mailbox Policy

Scripting agent can be used to do what my client wanted and I set it up for them. The scripting agent, when enabled, looks for a file named “ScriptingAgentConfig.xml” within the BinCmdletExtensionAgents. By default, a “ScriptingAgentConfig.xml.sample” file exists in the same location which gives an idea of the code that needs to go in the xml file. Open the sample file using notepad and understand the basic syntax the xml file needs.

Below is the basic syntax you need for the config xml file, irrespective of what you are trying to achieve. Pat Richard’s post helped me with the syntax.

            
            if($succeeded)
            {                PowerShell cmdlets            }

       
   
    

Below is the code that I used to achieve what my client wanted.

  

   
       
   
            if($succeeded)
            {

                $mailbox = $provisioningHandler.UserSpecifiedParameters["Alias"]

                Set-CASMailbox $mailbox -ImapEnabled $false -POPEnabled $false –ActiveSyncEnabled $false –OWAMailboxPolicy "HEW OWA Policy” –MAPIBlockOutlookRpcHTTP $true –MAPIBlockOutlookNonCachedMode $true

         Set-User -City ‘London’ -CountryOrRegion ‘United Kingdom’  -Company ‘How Exchange  Works’ -Identity $mailbox

                Set-Mailbox $mailbox -SingleItemRecoveryEnabled $true
                            }

       
         

The line explains that we want our code to run whenever a new-mailbox or enable-mailbox cmdlet runs successfully. Once one of the cmdlets (new-mailbox or enable-mailbox) runs successfully either via Shell, Console or custom applications, we are instructing the scripting agent to run a set of PowerShell cmdlets which all Exchange admins are familiar with. In our case, the cmdlets needed to run are Set-CASMailbox, Set-User and Set-Mailbox. We are storing the alias of the user to a variable ($mailbox) in our case to re-use in the commands below.

I copied the entire code below to notepad and saved it as ScriptingAgentConfig.xml inside BinCmdletExtensionAgents folder.

Next step is to enable the scripting agent. The agent should only be enabled once the ScriptingAgentConfig.xml is in place. Otherwise, all Exchange cmdlets except the “Get-noun” will throw errors. Run Enable-CmdletExtensionAgent “Scripting Agent” to enable the agent.

Time to test! I created a test mailbox and the scripting agent configured all the options my client wanted.

Now that you understand the power of scripting agent, you can automate tasks to make your life easier

Microsoft has released Service Pack 1 (SP1) for both Office 2010 and the Office Filter Pack 2010. While the first one interests a wider audience, the latter is only for Exchange admins & is only used as a prerequisite for Exchange 2010 Hub and Mailbox role installations. The Filter Pack is used to “filter” Office document contents and help with indexing it, for a better search result.

Download the Office 2010 SP1 here (32-bit) and here (64 bit).

Download the Office Filter Pack SP1 here

This is a question that comes up so frequently in forums and I have seen threads where the answers are wrong. Most Exchange admins are confused about this topic and end up adding it as part of the certificate to cover a “just in case” scenario.

Now, the answer to the question is that you DON’T need to add your CAS array URL to the certificate, if you have followed Microsoft recommendations. Only the urls that are used by the clients (via HTTPS) are needed on the SAN cert. Since a CAS array is MAPI only and doesn’t use SSL, it shouldn’t be part of the SAN cert. Below are the Microsoft recommendations around this topic.

• The CAS array url should be different to OWA, EAS, OA and EWS urls.
• Split-DNS is used (A general recommendation, not related to the CAS array issue though)
• You should use a url that isn’t resolvable from the internet as your CAS array.

In small environments or one with split-DNS model, Exchange admins configure the CAS array to be same as the OWA url and in that case, it becomes part of the SAN certificate anyway. From this “experience”, people start to answer in forums that the CAS array url SHOULD be part of the certificate. Microsoft recommendation to have the CAS array url to be completely different to any other urls will make you think as to whether it is needed

If the CAS array url is resolvable from the internet, Outlook Anywhere users will experience significant delay while connecting. Why? Outlook will try to use RPC to connect first as the url is resolvable, then waits for the timeout to kick in as the connection won’t be possible before establishing the connection using RPC over HTTPS. For a small shop or ones that doesn’t have Outlook Anywhere configured, this won’t be a big issue.

So, it is good to have your CAS array url to be something internal, like outlook.hew.local and configure an “A” record in the internal DNS pointing to the load balanced IP address.

Now, the next question that confuses admins is whether the NLB cluster name and SAN array name should be the same. NO, it doesn’t have to be. This means that the NLB cluster name and CAS server NETBIOS/FQDN doesn’t have to be part of the SAN cert as well. Make sure that the Exchange web services url and Autodiscoverserviceinternaluri are configured properly.

In short, the following is what you need on an Exchange 2010 SAN certificate (single site solution).

• OWA/EAS/OA/EWS url (like mail.domain.com, some companies go for one url per service).
• Autodiscover.domain.com, where domain.com is the email domain part of your user’s email address.
• Legacy.domain.com, if you are co-existing or thinking of co-existing Exchange 2010 with earlier versions.

No need for CAS array urls, NLB cluster names, CAS server NETBIOS or FQDNs! Hope this clears some confusion.

Microsoft has started supporting smart card authentication for Outlook Anywhere, provided that Outlook 2007 SP2 and Exchange 2010 SP1 is used (at the time of writing). The SSL should terminate on the CAS server. This throws reverse proxies like TMG 2010 out of the equation.

The prerequisites are:

• Exchange 2010 SP1 running on Windows Server 2008 R2 on CAS and Mailbox servers.
• SSL terminates on the Client Access server. The use of a network device that pre-authenticates SSL sessions in front of Exchange isn’t supported.
• All client Outlook connections must use Outlook Anywhere. After you have enabled smart card authentication for Outlook Anywhere, other connections, such as Outlook connecting over MAPI, won’t work.
• A physical smart card for each user that contains their user certificate. You can’t use software certificates stored in the local computer’s registry for this feature.
• Split DNS may also be required if you have configured different namespaces for internal and external client access.

Read the full story @ source

Microsoft has released Update Rollup 4 for Exchange 2010 SP1. As always, it is a cumulative update and can be applied straightaway without applying all the previous rollups. Forefront has to be disabled (fscutility /disable) while running the update rollup and enabled afterwards (fscutility /enable).

The setup checks whether the server has been configured to look for certification revocation list and advise to disable it, as the setup will take too long otherwise. Now, that is smart

Download the update rollup 4 here

After the issues with Update Rollup 3, my take will be to test the new rollup thoroughly in a test lab or wait a few days before rolling it into your production servers.

Yes, that is right. As an exchange admin, you don’t have to type in a password when you create a resource mailbox in Exchange 2010 SP1. The password boxes are greyed out.

It is a good move as resource mailboxes are not meant to be logged into! It will save few seconds too . You can reset the password of the disabled resource mailbox account using AD Users & Computers, if there is a need.

Passwords are still needed in the latest pre-SP1 build, Exchange 2010 with Update Rollup 5!

All Exchange admins are familiar with the SMTP banner. It is the response received by a remote server after it connects to the receive connector of an Exchange 2010 Hub or Edge server. If the SMTP banner is not set on a receive connector, the default response will have the fqdn of the server, along with the information that the server in use is a Microsoft one.

Below is the default response from my telnet client. As the internal information becomes visible to outside servers, exchange admins tend to change it.

I have seen companies using the “Specify the fqdn this connector will provide in response to EHLO” option in the receive connector as a means to set the banner. It is NOT the right way to do it.

The “banner” parameter of the Set-ReceiveConnector cmdlet needs to be used to configure the banner. Run the command below to set the banner. The banner text should start with 220, as stated in RFC 2821.

Set-ReceiveConnector –identity “ServerConnectorname” –Banner “220 banner text”

Once it is set, a telnet session will respond with the new banner.

Kemp Technologies has released a sizing guide (still in beta) for Exchange 2010, which compares the different load balancers they sell, depending upon our input. It is pretty much like the Microsoft Storage Calculator, except that the tool is only interested in parameters that affect the selection of a load balancer.

Depending upon the input given, the tool lists the load balancers that will meet the requirements.

Pretty good tool, check it out here

I had blogged sometime last year as to how to move the HUB transport database (mail.que and associated files) to a different location, read here. I was at a client site today and tried the same script & parameters (.Move-TransportDatabase.ps1 –QueueDatabasepath “path” –QueueDatabaseLoggingPath “path”), but it failed.

Though IPFilter was present in Exchange 2010, the script wasn’t looking for it. The IPFilter database stores the IP Allow Lists and IP Block Lists. So, I gave the IPFilter database path and log path, but it still failed.

I gave the Temp folder path and the script worked perfectly. So, the command to move the queue for Exchange 2010 SP1 server is as follows. Note that it has to be run from the scripts directory.

.Move-TransportDatabase.ps1 –QueueDatabasepath “path” –QueueDatabaseLoggingPath “path” –IPFilterDatabasePath “path” –IPFilterDatabaseLoggingPath “path” –TemporaryStoragePath “path”

A quick look at the Exchange 2010 SP1 folder structure for transport database has IPFilter, Queue and Temp folders.

You can edit the “EdgeTransport.Exe.Config” file in the Bin directory to change the queue location, but it doesn’t move the existing queue and the Transport service has to be restarted manually.

Running the command “.Move-TransportDatabase.ps1 –QueueDatabasepath “path” –QueueDatabaseLoggingPath “path” works fine in Exchange 2010 with Update Rollup 5. So, the change in using the script only affects 2010 SP1 deployments.

Distribution Group Naming Policy is a template that, we as Exchange admins, apply to all newly created distribution groups. I had explained all about configuring and using naming policy in one of my previous posts, read it here.

There will be times in which you want to cerate a distribution group with a particular name, without getting the standard policy applied. You can create new groups or modify existing ones, ignoring the naming policy been configured.

To create a new distribution group named “Executives”, without the naming policy being applied, run

New-DistributionGroup –Name “Executives” –IgnoreNamingPolicy

The group gets created without having a “DL_” as a prefix in my lab. “DL_” as a prefix is my naming policy in this test lab.

To modify an existing group which has naming policy applied already, run

Set-DistributionGroup "-identity “DL_ExchangeTeam” –Name “#ExchangeTeam” –DisplayName “#ExchangeTeam” –IgnoreNamingPolicy