Category Archives: 13179

Improvements to the Exchange Remote Connectivity Analyzer




The Exchange Remote Connectivity Analyzer (ExRCA) has to be one of the best troubleshooting tools that the Exchange product team has ever produced.  It’s a one-stop shop that allows you to test remote connectivity to an Exchange organization using Autodiscover, ActiveSync, Outlook Anywhere, Web Services, or inbound/outbound SMTP from a Microsoft hosted cloud application on the Internet.  It works with both on-prem and Office 365 Exchange organizations.



Shawn McGrath is the developer in charge of ExRCA development and previewed recent improvements to us at the MVP Summit in February 2012.  I’m pleased to say that ExRCA version 1.4 has now been released!  The biggest changes are around the CAPTCHA experience, which I’ve been a vocal about for the past year.  Constructive Feedback = Good.  J



Here’s a list of the changes in this release:

  • We are using a new CAPTCHA service provided by an internal team.
  • The challenge is NOT case sensitive, so it doesn’t matter if you type upper or lower case letters.  We also note this on the web page.
  • The CAPTCHA challenges will not include hard to distinguish letters/numbers.  For example 2 and Z or O and 0.
  • If you get the challenge wrong, the password entries will not be removed.
  • Once you enter a correct response to the challenge, you will be verified for a set amount of time (~30 minutes).  This means you will not see additional CAPTCHA challenges until the timeout period expires.
  • The inbound SMTP test now inserts the IP address of the user performing the test into the test email message. The IP is also inserted into an SMTP Header (X-Originating-IP).
  • Fixed an issue in the Sender-ID test where certain DNS responses while evaluating the “exists” mechanism were incorrectly being treated as a TempError
  • The outbound SMTP Sender-ID tests now conform to the RFC specified limit of ten DNS-based mechanisms that can be used during the evaluation of the SPF record.
  • Fixed an issue where host names with all numbers in the top-level domain were not considered valid input
  • Fixed user interface issues that can cause the “helper bubble” to stick around when navigating in the wizard
  • Added a note to the EWS service account access test indicating that the mailbox must be empty
  • Changed the Windows Mobile Certificate test to warn instead of fail when certificates aren’t trusted by Windows Mobile since many other devices also use ActiveSync and may trust the certificate
  • Changed the Outlook Anywhere mutual authentication test to report a warning instead of an error when the mutual authentication (msstd: string) only matches a Subject Alternative Name on the certificate. Windows Vista SP1 and later can handle this configuration.
  • The Outlook Anywhere Proxy Ping and HTTP Authentication Method Tests now use the full query string; this is necessary to support certain UAG configurations.
  • Added additional error mappings for known issues

Shawn also created this fun video to demonstrate the new CAPTCHA
experience.





 

Exchange 2010 support for host-based failover clustering and migration




Some Exchange-supported virtualization platforms, such as Hyper-V and VMware include features that support the clustering or portability of guest virtual machines across multiple physical root machines.  Examples of host-based failover clustering and migration include Hyper-V Live Migration and VMware ESX vMotion.



Microsoft support for host-based failover clustering and migration virtualization with Database Availability Groups (DAGs) depends on the Exchange 2010 service pack level.  Per the Exchange 2010 System Requirements:



With Exchange 2010 RTM:

Microsoft doesn’t support combining Exchange high availability solutions (such as DAGs) with hypervisor-based clustering, high availability, or migration solutions that will move or automatically failover mailbox servers that are members of a DAG between clustered root servers. DAGs are supported in hardware virtualization environments, provided the virtualization environment doesn’t employ clustered root servers, or the clustered root servers have been configured to never failover or automatically move mailbox servers that are members of a DAG to another root server.

With Exchange 2010 SP1 (or later) deployed:

Exchange server virtual machines (including Exchange Mailbox virtual machines that are part of a DAG), may be combined with host-based failover clustering and migration technology, as long as the virtual machines are configured such that they will not save and restore state on disk when moved, or taken offline. All failover activity must result in a cold boot when the virtual machine is activated on the target node. All planned migration must either result in shutdown and cold boot, or an online migration that makes use of a technology like Hyper-V Live Migration. Hypervisor migration of virtual machines is supported by the hypervisor vendor; therefore, you must ensure that your hypervisor vendor has tested and supports migration of Exchange virtual machines. Microsoft supports Hyper-V Live Migration of these virtual machines.


In summary, Exchange 2010 SP1 or better supports hypervisor migrations such as Hyper-V Live Migration and VMware ESX vMotion for DAG member servers.  Host-based failover cluster migrations, such as Hyper-V Quick Migration, is supported only if the virtual Exchange DAG server is restarted immediately after the quick migration completes.  Exchange 2010 RTM is not supported with either migration technology.  RTM only supports the native Exchange high availability features present in DAGs.



Other Exchange Server 2010 roles (CAS, Hub Transport, Edge Transport, and Unified Messaging) fully support host-based failover clustering and migration because they do not employ native Exchange high-availability solutions.



For a list of the virtualization platforms supported by Exchange, visit the Windows Server Virtualization Validation Program website.

Adjusting Exchange 2010 DAG Failover in High Latency Networks

Some Exchange 2010 DAG implementations have DAG members that are separated by high latency WAN networks.  In these networks you may find that the increased latency causes unexpected DAG failovers or failures. 



This is especially likely to happen with a two node DAG with a File Share Witness (FSW).  When network latency increases to the point that the cluster heartbeat threshold is reached, the node furthest from the FSW will go offline.  The node that’s in the same LAN as the FSW will stay online because it maintains quorum.



There are two properties that specify cluster health, as measured in heartbeats.

  • CrossSubnetDelay specifies the heartbeat interval (in milliseconds) between subnets. The default is 1000 milliseconds (1 second).
  • CrossSubnetThreshold specifies how many heartbeats can be missed between subnets before cluster failover (or failure) occurs. The default is 5 heartbeats.

With the default settings, any WAN latency that causes 5 missed heartbeats over 5 seconds causes the cluster to fail. This matches the settings used by the SameSubnetDelay and SameSubnetThreshold properties.



If WAN latency causes unexpected cluster failover or failures, adjust the CrossSubnetDelay value to its maximum value of 4000 milliseconds (4 seconds) and the CrossSubnetThreshold property to its maximum value of 10,  With these settings the cluster will not failover or fail until there are 10 missed heartbeats, 4 seconds apart (40 seconds).



This is accomplished from Powershell by doing the following:



  • From one of the DAG members open the Windows Powershell Modules in Administrative Tools.  This will launch Powershell and import all the Windows Powershell modules for installed features, including the new Windows Failover Cluster module.
  • Run the following one-liner to configure the maximum values:



$cluster = Get-Cluster; $cluster.CrossSubnetThreshold = 10; $cluster.CrossSubnetDelay = 4000



  • Check your settings using the following cmdlet:

Get-Cluster | fl *




Since cluster properties are instantly replicated between all nodes in the cluster, this only needs to be configured from one node in the DAG.  The changes go into effect immediately and there is no need to restart services or the server.



Note that you can configure the same properties using cluster.exe, but I’m using Powershell here because cluster.exe is deprecated in Windows Server 2008 R2.

Exchange DAG Cluster Service Terminated with Error 7024

I ran into an interesting issue at a client site yesterday on an Exchange 2010 SP1 DAG member.  One DAG member’s databases would not mount (even Public Folders) and the Cluster service would not start.  The DAG is configured as a three member stretched DAG, with two nodes in the main site and another in the DR site.



The event IDs logged were:



Log Name:      System
Source:        Service Control Manager
Date:          10/23/2011 12:07:44 AM
Event ID:      7024
Task Category: None
Level:         Error
Keywords:      Classic
User:          N/A
Computer:      EX03.domain.local
Description:
The Cluster Service service terminated with service-specific error Log service encountered an invalid log block..



Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          10/23/2011 12:00:43 AM
Event ID:      1177
Task Category: Quorum Manager
Level:         Critical
Keywords:     
User:          SYSTEM
Computer:      EX03.domain.local
Description:
The Cluster service is shutting down because quorum was lost. This could be due to the loss of network connectivity between some or all nodes in the cluster, or a failover of the witness disk.
Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapter. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.



Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          10/23/2011 12:00:43 AM
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:     
User:          SYSTEM
Computer:      EX03.domain.local
Description:
Cluster node ‘EX02′ was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.



Log Name:      System
Source:        Microsoft-Windows-FailoverClustering
Date:          10/23/2011 12:00:43 AM
Event ID:      1135
Task Category: Node Mgr
Level:         Critical
Keywords:     
User:          SYSTEM
Computer:      EX03.domain.local
Description:
Cluster node ‘EX01′ was removed from the active failover cluster membership. The Cluster service on this node may have stopped. This could also be due to the node having lost communication with other active nodes in the failover cluster. Run the Validate a Configuration wizard to check your network configuration. If the condition persists, check for hardware or software errors related to the network adapters on this node. Also check for failures in any other network components to which the node is connected such as hubs, switches, or bridges.

The cluster failed when two of the three DAG members (EX01 and EX02) went offline at 12:00:43 AM due to a network failure in the active site.  For some reason, this corrupted the CLUSDB.BLF file on the member in the DR site which prevented that node from coming online when the network came back up.  CLUSDB.BLF is a CLFS Base Log File used by the cluster service which contains metadata that is used to manage access to the log data. 



To correct the problem, navigate to the %WINDIR%\Cluster folder and rename CLUSDB.BLF to CLUSDB.BLF.OLD.  Then restart the Exchange server.  The cluster service will generate a new CLUSDB.BLF file on restart.  The cluster service will be able to start and the databases will mount.

Cloning Exchange Remote IP Ranges Between Connectors

I’ve been doing a number of Exchange 2007 to 2010 migrations lately.  Most of these customers have internal relay Receive Connectors that allow internal application servers to relay SMTP email through Exchange to internal and/or external recipients.  The connectors are configured to allow only certain IP addresses to use them, and often it’s a pretty extensive list.  This article explains how to copy, or “clone”, these remote IP addresses from one connector to another.



For example, here’s an Exchange 2007 connector with over 25 remote IP addresses that are allowed to use this connector:






Typing in these IP addresses into a new Exchange 2010 Receive Connector is not only laborious, it can lead to errors that may take quite a bit of time to troubleshoot.



Using Powershell we can easily clone this set of IP addresses from an existing connector, named Anonymous Relay on EX2007HT, to another connector with the same name on an Exchange 2010 Hub Transport server, EX2010HT.



Begin by creating a Receive Connector on the target server, EX2010HT with the name Anonymous Relay and configure it with the appropriate permissions.  Then run the following cmdlets to clone the RemoteIPRanges attribute:

$connector = Get-ReceiveConnector “EX2007HT\Anonymous Relay”
Set-ReceiveConnector “EX2010HT\Anonymous Relay” -RemoteIPRanges $connector.RemoteIPRanges

You can use this method to copy any remote IP range from one connector to another.  Simply replace the server\connector names.

How to Configure Exchange 2010 SP1 Federation

Exchange federation allows different Exchange organizations to share free/busy information with each other.  It does this without having to configure a one- or two-way trust between the organizations.






Federation is accomplished using the Microsoft Federated Gateway server, a free cloud-based service offered by Microsoft.  The Microsoft Federated Gateway (MFG) server acts as a trust broker between federated organizations, similar to the way a trusted root CA works for certificates.  All organizations that use federation must configure a one-time federation trust with the MFG, and orgs that share free/busy information must have an Organization Relationship with the other org(s) they want to share with.  Organization Relationships (sometimes called sharing policies) can be one-way, meaning that CompanyABC can share free/busy info with CompanyXYZ, but not necessarily the other way around.  Usually, each org will have a reciprocal Organization Relationship with the other org so they can see each other’s calendar data.



There are a number of articles that explain how to configure federation, but all of them are for Exchange 2007 or Exchange 2010 RTM.  Exchange Server 2010 SP1 simplifies federation configuration, primarily by eliminating the requirement for a trusted-CA certificate and providing most of the federation configuration from the Exchange Management Console (EMC).



Microsoft also changed the Microsoft Federation Gateway servers in Exchange 2010 SP1.  The RTM version uses what Microsoft calls the “consumer instance” of MFG and requires a trusted certificate for federation.  SP1 uses the same Microsoft Online Services MFG used by the Business Productivity Online Suite (BPOS) and Office365, Microsoft’s cloud offerings.  This new Online Services MFG uses self-signed certificates for federation (recommended), but can also still use trusted third-party certs.



The following guide explains how to configure federation between two Exchange 2010 SP1 organizations.



Note: This article assumes there is a working autodiscover record for the partner organization.  Federation uses autodiscover to automatically configure the Organization Relationship for the remote org.  If autodiscover is not working, you will need to enter that information manually.



Create a new Federation Trust

  • Open the Exchange Management Console (EMC) and select the Organization Configuration node.
  • In the Actions pane, select New Federation Trust.  The New Federation Trust wizard will run.
  • Click New to form the new trust with the Microsoft Federation Gateway.  The wizard will create a new self-signed certificate called Exchange Delegation Federation with the subject name of Federation.  The Federation and SMTP services will be assigned to this certificate, but it will not change the default SMTP certificate.  The Microsoft File Distribution service will automatically copy and install this self-signed certificate to all of your Exchange 2010 client access servers.
  • Click Finish to close the wizard.



Create Domain Proof Records

Domain Proof records are TXT records created in your domain’s external DNS zone.  The purpose of these TXT records is to prove the identity of your domain for the trust with the MFG server.  Exchange SP1 requires that you have at least two TXT records, one dedicated for domain delegation (typically, exchangedelegation.companyabc.com) and another for each SMTP domains you use for users (for example, companyabc.com).



Run the following cmdlets from the Exchange Management Shell (EMS) to generate the domain proof values:



Get-FederationDomainProof -DomainName exchangedelegation.companyabc.com
Get-FederationDomainProof -DomainName companyabc.com



Repeat the second cmdlet for additional SMTP domains you want to federate, if any.



Each cmdlet will generate a unique Proof value, based on a hash using the Exchange Delegation Federation self-signed certificate.  If the MFG can read the domain proof value in an external DNS record and it matches the calculated value, it proves domain ownership and validates the trust.






You must create one TXT record in external DNS for each of the Proof values.  How you do this depends on your external DNS management platform.  Here’s how that looks for Microsoft DNS:






And here’s how it may look in a managed DNS web GUI:





Remember, these TXT records should be entered in your external DNS, not internal.  You may need to wait a bit for the new TXT records to propagate across the Internet.  You will be unable to manage the federated domains until the MFG servers can access the domain proof TXT records.



Manage the Federated Domains

Once the domain proof TXT records have propagated you can add the federated domains to the Federation Trust.  But before we can add the federated domains, we must first add the new exchangedelegation.companyabc.com namespace to the Accepted Domains on the hub transport configuration.

  • Back in the EMC navigate to Hub Transport in the Organization Configuration node.
  • Click the Accepted Domains tab and click New Accepted Domain in the Actions pane.
  • Enter Exchange Federated Delegation for the Name and enter exchangedelegation.companyabc.com for the Accepted Domain, then click New.  This new authoritative accepted domain will never be used by users – it is only used by the federated trust.




  • Click the Organization Configuration node and select the Microsoft Federation Gateway trust under the Federation Trust tab.
  • Click Manage Federation in the Actions pane.  You will see the current federation certificate status.  You can click Show distribution state to check that the federation certificate is installed on all Exchange 2010 client access servers. 
  • Click Next to bring up the Manage Federated Domains window. 
  • Click Add and select the Microsoft Federated Trust accepted domain you created earlier.  I recommend adding just the Microsoft Federated Trust first, which creates the delegation namespace on the MFG server, the unique Application Identifier (AppID) and Application URI.  Then go back and add the SMTP domain(s) you want to federate (i.e., companyabc.com).


  • Click Next and Manage to configure Microsoft Federated Trust.  When the configuration is successful you will see the federation trust has an Application Identifier and Application URI.




  • If the TXT records you created earlier are incorrect or have not propagated yet to the MFG server, you will get the following error:

Error:
Proof of domain ownership has failed. Make sure that the TXT record for the specified domain is available in DNS. The format of the TXT record should be “example.com IN TXT hash-value” where “example.com” is the domain you want to configure for Federation and “hash-value” is the proof value generated with “Get-FederatedDomainProof -DomainName example.com”.
The proof of domain ownership is not valid or is missing.

  • Once you have configured the original Microsoft Federated Trust you can repeat these steps to add your other accepted domains.  You can only add accepted domains that you have created domain proof TXT records for.



Create Organization Relationships

Now that the federated trust has been created and then validated by the MFG, you can create organization relationships.  These are the federation sharing policies that determine what is shared with whom.

  • Click the Organization Relationships tab on the Organization Configuration node in the EMC.
  • Click New Organization Relationship in the Actions pane.  The New Organization Relationship wizard will start.
  • Enter a name, such as Share with CompanyXYZ.
  • Select the Enable free/busy information access checkbox and specify the free busy data access level you wish to share using the dropdown box.
  • You may select a security group for which this relationship should apply.  If you do not select a security group the settings will apply for all users.




  • Click Next to enter the External Organization details.
  • Enter the domain you want to federate with (i.e., companyxyz.com), then click Next and New.  Exchange will create a new organization relationship using the data results from the Get-FederationInformation cmdlet.  If the external domain does not have a valid federation trust with the MFG or autodiscover record, you will see an error:

Error:
Federation information could not be received from the external organization.

  • When the organization relationship has been successfully configured you will see it listed under the Organization Relationships tab.  Sharing Enabled and Calendar enabled will show as True.



Testing and Troubleshooting

Use the following command to query for TXT records in DNS:



nslookup -q=txt companyabc.com [DNS server name to query]



Use the following cmdlets to get Exchange federation configuration information:

  • Get-FederatedOrganizationIdentifier – gets the Microsoft Exchange Server 2010 organization’s federated organization identifier and related details, such as federated domains, organization contact, and status.  The Enabled attribute will show as False until the MFG has validated the trust using the domain proof TXT records in external DNS.
  • Get-FederationInformation – gets federation information, including federated domain names and target URLs, from an external Exchange organization.  It does this using the autodiscover record of the external domain.  This cmdlet will not work until you have a valid Federated Trust configured.
  • Get-FederationTrust – displays the federation trusts configured for the organization.  Use with Format-List to display the ApplicationIdentifier and ApplicationUri attributes, details about the federation certificates. and token information.
  • Get-OrganizationRelationship – gets settings for a relationship that has been created for free/busy information access or secure e-mail delivery using federated delivery.

If you’re federating with a mixed-mode Exchange organization with Exchange 2003 users (as in a migration scenario) you will need to populate the TargetSharingEpr attribute of the Organization Relationship with that domain.  If you don’t populate this value the free/busy information for Exchange 2003 users will be unavailable.  Populate the TargetSharingEpr value  in both organizations with the following cmdlet:



Set-OrganizationRelationship “CompanyABC” -TargetSharingEpr https://mail.companyabc.com/EWS/Exchange.asmx/WSSecurity

Replace mail.companyabc.com with the FQDN used by the external organization’s Exchange Web Services (EWS) ExternalURL.  For example, run the following cmdlet in CompanyABC:



Get-WebServicesVirtualDirectory -Server ex2010 | fl ExternalUrl

ExternalUrl : https://email.companyabc.com/ews/exchange.asmx



CompanyXYZ should set Organization Relationship’s TargetSharingEpr for CompanyABC to https://email.companyabc.com/EWS/Exchange.asmx/WSSecurity



Continuing the example, run the same cmdlet in CompanyXYZ:



Get-WebServicesVirtualDirectory -Server exchange01 | fl ExternalUrl

ExternalUrl : https://webmail.companyxyz.com/ews/exchange.asmx



CompanyABC should set Organization Relationship’s TargetSharingEpr for CompanyXYZ to https://webmail.companyxyz.com/EWS/Exchange.asmx/WSSecurity


Fix for "Default Policy" with mailbox manager settings cannot be managed by the current version of Exchange Management Console

I’m doing an Exchange 2007 to Exchange 2010 migration for a client and found that the Address Lists and E-mail Address Policy had not been updated from Legacy Exchange 2003 policies when they upgraded to 2007.  Typically, these are converted from Legacy policies in Exchange 2007 or 2010 by adding an RecipientFilter OPATH filter.



Exchange 2003 Mailbox Management policies were replaced by Messaging Records Management (MRM) in Exchange 2007.  During the migration from Exchange 2003, you’re supposed to create new MRM policies to match your Exchange 2003 Mailbox Manager polices and then remove the 2003 policies using the Exchange 2003 Management Console.



The customer didn’t do this before Exchange 2003 was decommissioned, so I’m doing it now in the 2010 migration.  But as I tried to convert the Default Policy in E-mail Address Policies using the Set-EmailAddressPolicy “Default Policy” -IncludedRecipients AllRecipients command, I get the following error:



Set-EmailAddressPolicy : The recipient policy “Default Policy” with mailbox manager settings cannot be managed by the current version of Exchange Management Console. Please use a management console with the same version as the object.
At line:1 char:23
+ Set-EmailAddressPolicy  <<<< “Default Policy” -IncludedRecipients AllRecipients




This happens when the Default Policy also includes Mailbox Manager settings.  Since there are no Exchange 2003 servers anymore (or 2003 console) in this environment, I can’t remove the Mailbox Manager settings from the policy.  Here’s how to fix this using ADSI Edit:

  • Run ADSI Edit from the Exchange 2010 server.
  • In the Configuration container, navigate to CN=Recipient Policies,CN=<Exchange Org>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<com>
  • In the middle pane, view the properties of the Default Policy.
  • Remove the value(s) of the MsExchMailboxManagerFolderSettings attibute so that it’s now <Not Set>
  • Edit the MsExchPolicyOptionList attribute and remove all the attributes that do not begin with 0xfc.  The policy that begins with 0xfc is the email addressing policy.
Now when you run Get-EmailAddressPolicy “Default Policy” | FL you will see that HasMailboxManagerSetting is set to False and you will be able to update the Default Policy.

How to remove Exchange 2003 Mailbox Manager settings without the 2003 Management Console

I’m doing an Exchange 2007 to Exchange 2010 migration for a client and found that the Address Lists and E-mail Address Policy had not been updated from Legacy Exchange 2003 policies when they upgraded to 2007.  Typically, these are converted from Legacy policies in Exchange 2007 or 2010 by adding an RecipientFilter OPATH filter.



Exchange 2003 Mailbox Management policies were replaced by Messaging Records Management (MRM) in Exchange 2007.  During the migration from Exchange 2003, you’re supposed to create new MRM policies to match your Exchange 2003 Mailbox Manager polices and then remove the 2003 policies using the Exchange 2003 Management Console.



The customer didn’t do this before Exchange 2003 was decommissioned, so I’m doing it now in the 2010 migration.  But as I tried to convert the Default Policy in E-mail Address Policies using the Set-EmailAddressPolicy “Default Policy” -IncludedRecipients AllRecipients command, I get the following error:





Set-EmailAddressPolicy : The recipient policy “Default Policy” with mailbox manager settings cannot be managed by the current version of Exchange Management Console. Please use a management console with the same version as the object.
At line:1 char:23
+ Set-EmailAddressPolicy  <<<< "Default Policy" -IncludedRecipients AllRecipients




This happens when the Default Policy also includes Mailbox Manager settings.  Since there are no Exchange 2003 servers anymore (or 2003 console) in this environment, I can’t remove the Mailbox Manager settings from the policy.  Here’s how to fix this using ADSI Edit:

  • Run ADSI Edit from the Exchange 2010 server.
  • In the Configuration container, navigate to CN=Recipient Policies,CN=<Exchange Org>,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=<domain>,DC=<com>
  • In the middle pane, view the properties of the Default Policy.
  • Remove the value(s) of the MsExchMailboxManagerFolderSettings attibute so that it’s now 
  • Edit the MsExchPolicyOptionList attribute and remove all the attributes that do not begin with 0xfc.  The policy that begins with 0xfc is the email addressing policy.
Now when you run Get-EmailAddressPolicy “Default Policy” | FL you will see that HasMailboxManagerSetting is set to False and you will be able to update the Default Policy.

Error Running new-TestCasConnectivityUser.ps1

I ran into a strange problem running the new-TestCasConnectivityUser.ps1 script at a client today. When I ran the script to create the test account on a new Exchange installation, I received the following error:



CreateTestUser : Mailbox could not be created. Verify that OU ( Users ) exists and that password meets complexity requirements.








I verified that I could create a user account in the User container in AD just fine using the same password I supplied in the script. Obviously, I had sufficient rights and the password was complex enough.



After examining the new-TestCasConnectivityUser.ps1 script I noticed that the $OrganizationalUnit variable is looking for a match in AD for “Users”. A quick search using AD Users and Computers found that the client had many OU’s named Users throughout AD. The script was actually bombing out because it didn’t know which “Users” OU to use.



The fix is to add the following line below line 171 in the script to make it look for a better match:



OrganizationalUnit = “CN-Users,DN=domain,DN=com”






Then save the script and run it.

TechEd 2011: Day 2 Review and Random Photos

Second day is nearly done.  I started off with another Laura Chappell session, “We Don’t Need No Stinkin’ GUI: Command-Line Capture Techniques (Remote Options)”.   It sounded good when I signed up for it, but it wasn’t right for me.  Unfortunately, it was on the far side of the planet and took a very long time to get to my second choice, “Hyper-V and Dynamic Memory in Depth”.  This was a better fit and I enjoyed what I saw of it.



Next up was “Best Practices for Virtualization for Microsoft Exchange 2010″ which I decided to attend because of the new virtualization support agreement. Now that Live Migration is supported, I asked if vMotion is, as well.  The answer was, “We support Live Migration type technologies, as long as they’re on the virtualization support list.”  Throughout the sessions, I’ve decided to tweet important points that are discussed or mentioned.  Follow me on Twitter if you’d like to keep up.  WIFI is much better this year and I’ve not found any connectivity issues so far.



The next session was “Load Balancing with Microsoft Exchange 2010″.  Really good session and demo with F5 hardware load balancers.  Awesome equipment and this was one of the best deep-dive sessions so far.  Lots of good info, but it was covered fast.  There was really nothing new in this session from last year, but if you want to do a proper large-scale deployment you have to get the load balancers right.



Attendees evaluating their swag



Some of The Krewe



Stephen Rose (Sprinboard), Adam Carter (Channel 9/Edge)


Michael Bender (@TheKrwe) and Jessica from Xiotech