If you’re using a load balancer with Exchange 2010 you’ll be wanting to fix the two ports (RPC Client Access and Address book) used for Outlook connectivity (note – this is for non Outlook Anywhere connections), these ports are set on all client access servers, and the RPC Client access port on public folder servers.

If static ports are not configured then every Client Access Server / Public folder server will randomly select ports between 49152-65535 (Server 2008 onwards) to use requiring you to load balance all of those ports – something which could cause resource exhaustion on your load balancer.

To configure static ports two registry entries are required – both are used on Client Access Servers, only one on Public folder servers.

To configure the Address Book key (Client Access Servers only) navigate to the HKLM:SystemCurrentControlSetservicesMSExchangeAB key, create a sub-key called Parameters, then create a String value called ‘RpcTcpPort’ with a value between 49152 – 65535, I chose 60002 in this example:

To configure the Exchange RPC Client Access key (Client Access Servers and Public folder servers) navigate to the HKLM:SystemCurrentControlSetservicesMSExchangeRPC key, create a sub-key called ParametersSystem, then create a String value called ‘TCP/IP Port’ with a value between 49152 – 65535, I chose 60001 in this example:

Once the key has been set the Microsoft Exchange Address Book (Client access servers) and Microsoft Exchange RPC Client Access (Client access and Public Folder servers) services require restarting, once this has been done the netstat command shows our ports:

That shows us that we have two processes, each listening on one port, the final column show’s the PIDs of the processes responsible for those ports, 9092 for 60001 and 12624 for 60002, using task manager I can see the name of the processes associated with those PIDs:

So we can see that our RPCClientAccessService and AddressBook services are responsible for the open ports.

As a side note when configuring your load balancer your should follow the guidance here: http://technet.microsoft.com/en-us/library/ff625248.aspx which details affinity requirements for Exchange client protocols, in our example you would need to load balance 135 (initial connections are made on this port & the RPC service which listens on it returns to the Outlook client which ports it should connect to, which of course will be the static ports listed above) and ports 60001, 60002 (RPC Client access and Address Book services).

The aim of this post was to document the static port setting process & provide some background on why you might do it, this is generally done when using load balancing of some description – which is a whole other topic in itself which I’ve not covered here.  There is some excellent Technet documentation available on the subject here: http://technet.microsoft.com/en-us/library/ff625248.aspx, I hope to provide some blog posts around HLB (Hardware Load Balancers) & their configuration / integration with Exchange in due course.

Rob

Many of my customers use Exchange Active Sync (EAS) to provide user’s access to their mailboxes whilst they’re on the move, as someone who is field based it’s invaluable, alongside this device policies are generally implemented to enforce a PIN code, encrypt the data on the device etc…

The main issue with the above is generally any user with an exchange account can use EAS to connect to their mailbox, this may or may not be a problem dependant on your organisation, for example if you require encryption to be used on the mobile device and a user connects a device claiming to support encryption (but it doesn’t, no prizes for pointing out which manufacturer fell foul of this) then you potentially have sensitive data on an easily lost mobile device.

We have a number of options to control EAS access, firstly if you’re using a reverse proxy such as TMG and you’re pre-authenticating your users at TMG you can restrict access based on Windows group membership – only allowing those users who have been issued with corporate mobile devices.  That’s a good start, however it doesn’t stop a user who is granted access from connecting any device they like.  To get device based control you need to break out Exchange PowerShell and use the Set-CasMailbox, Set-ActiveSyncOrganizationSettings and New-ActiveSyncDeviceAccessRule commandlets. 

In this scenario I am going to change the default settings for the organisation to quarantine a new EAS device, notify the administrator and then create specific rules for users who require EAS access (much the same as you would configure a firewall, start with no access and then grant it as required).

Firstly to set the Organisation policy to  quarantine new devices and notify my two administrators, Bob and Dave:

Set-ActiveSyncOrganizationSettings -DefaultAccessLevel Quarantine -AdminMailRecipients bob@risual.com, dave@risual.com

Now when users connect using EAS to their mailbox they will not be permitted, as well as this they will receive and email from Exchange with the following subject:

“Your mobile phone is temporarily blocked from synchronizing with the server while permission to access is being verified.”

Our two administrators will also receive an email, with the following subject:

“The mobile phone that belongs to domainuser has been quarantined. Synchronization with the server via Exchange ActiveSync is blocked until you take action.”

In the body of this email the device ID of the EAS device which is trying to connect is listed, to allow our user to connect with that device the set-casmailbox commandlet should be used:

Set-CASMailbox –Identity user@domain.com –ActiveSyncAllowedDeviceIDs <deviceid from admin email>

Our user’s device will then be allowed to synchronise with Exchange and all will be well.  This is fine, except if you have 1000’s of users with devices, it quickly becomes very tedious for the Administrator, another solution is to allow access based on the Device Model and / or Device Type (for example your organisation probably issues largely the same devices to all users), this is achieved using the New-ActiveSyncDeviceAccessRule commandlet to allow all your specific devices, there are several way’s to find out what your device model / type is, in the email sent to a user informing them that their device cannot connect the body contains this information, another way is to use Get-ActiveSyncDeviceStatistics:

[PS] C:Windowssystem32>Get-ActiveSyncDeviceStatistics -Mailbox rob

RunspaceId                    : b30b569e-eee9-49a8-ac08-1a4a5ce3cc27

FirstSyncTime                 : 21/04/2010 08:58:08

SyncStateUpgradeTime          :

As you can see in this example I have an iPhone conneected to my lab mailbox, the two fields that we’re interested in are device model and device type, you may have also noticed the DeviceID field, this is the same value which is used in my earlier example with set-casmailbox, another way of viewing the information is to use the Phone tab within ECP, you can drill down and view some of the information available in the above commandlet:

So to allow our device globally we use the New-ActiveSyncDeviceRule commandlet:

New-ActiveSyncDeviceRule –QueryString iPhone – Characteristic DeviceModel –AccessLevel Allow

This will create a rule allowing devices reporting their devicemodel as ‘iPhone’ to connect to Exchange using EAS.

Rob

On server 2008r2 you can do import-module servermanager & then add-windowsfeature to configure features etc.. from PowerShell, this doesn’t exist out of the box on 7, however if you install this: http://code.msdn.microsoft.com/PSClientManager you have an equivalent set of modules

Handy eh!

Rob

As part of a larger project I’ve been involved with which uses an IIS7 web application (I’ve been helping the client with their infrastructure and integrating the application with AD) we hit an issue where some 3rd party pieces of code were using absolute links *tut tut*! rather than relative ones, this had the side effect that a user would start off their session using an SSL secured https session & after performing certain tasks would find themselves on http.  Not ideal!  The application also has a requirement that the web servers are able to connect to themselves on port 80 – this could not be changed & interfering with this connection would break functionality.

To resolve this I’ve implemented the Microsoft URL Rewrite module 2 for IIS7, with the following configuration:

1. Download and install the IIS URL re-writing module: http://www.iis.net/download/urlrewrite
2. Go to the site in IIS manager & navigate to URL Rewrite in the right hand pain
3. Create a new inbound rule with the following settings:
4. Match URL:
1. Requested URL: ‘Matches the pattern’
2. Using: ‘Regular Expressions’
3. Pattern: ‘(.*)’
4. Ignore Case: ‘True’
5. Conditions:
1. Input ‘{HTTPS}’ Type ‘Matches the pattern’ Pattern ‘^OFF$’
2. Input ‘{LOCAL_ADDR}’ Type ‘Does not match the pattern’ Pattern ‘127.0.0.1’
6. Action: ‘Redirect’ Redirect URL: ‘https://{HTTP_HOST}/{R:1}’ Append Query String: True Redirect type: ‘See Other (303)’

This will not only correct broken URLs which get returned but will redirect users who hit the site via http to https which is a requirement for the service.

Handy fix – I’d often use TMG / ISA to resolve this but this customer’s solution does not feature those products (the site is being deployed internally).

Rob

As part of a recent engagement I was asked to implement a solution to automatically export & archive System and Security logs from servers to a central location, the requirements were:

• Nightly time stamped archive of Security and System event logs to a central location
• Clear the local log once the archive has been successfully taken

I put together the following PowerShell script to achieve the above:

$locallocation = "c:logs"
$remotelocation = "\fileserverEventLogs"
$localmachine = $env:computername

$evtlgs = Get-WMIObject -Class Win32_NTEventLogFile -Computer $localmachine
foreach ($log in $evtlgs)
    {
    if ($log.LogFileName -eq "System" -or $log.LogFileName -eq "Security")
        {
        $timestamp = get-date -f yyyyMMddHHmmss
        $path = $log.LogFileName + $timestamp
        $store = $locallocation+$path+".evt"
        $backup = ($log.backupeventlog($store)).ReturnValue
        if($backup -eq 0)
            {
            $log.ClearEventLog() | out-null
            }     
        move-item $locallocation* $remotelocation$localmachine
        }
    }

The above script is executed by a Scheduled Task (which on another note are brilliant on Server 2008), the lines you’re interested in are the top 2 lines which configure a local location to write the log out to and the remote location to move the log to once it has been written.  I ran this script using a service account which has permission to write to the local and remote locations. 

If you wanted a different selection of logs to be archived you would adjust the

if ($log.LogFileName -eq "System" -or $log.LogFileName -eq "Security")

line to suit your requirements.

In our requirement the logs had to be archived daily, this was simply achieved by configuring task scheduler to run once per day at the desired time, no code changes are required. 

The requirement for only clearing the local log if the export was successful is met by checking the exit code form the backup, if this wasn’t 0 then the log wont be cleared.

I recently hit a problem with CWA being published behind TMG, CWA was accessible internally from a terminal server but would throw the above error when login was attempted via TMG’s reverse proxy. 

The solution (for me – there is a fair bit written about this involving SPNs which were not the issue in this case), was to enable anonymous authentication on the AuthMainCommandHandler.ashx file (within the /cwa directory) within IIS & all is well again, it is reported that this issue only occurs on Server 2008 & is an issue with the site creation wizard.

My colleague Simon also hit this issue publishing CWA behind UAG, so worth checking.

SharePoint is not my usual topic of conversation I will admit, however this caused me pain & isn’t documented from what I could find.

For what ever reason my local SharePoint workspace recently broke, giving me this error when I tried to launch it:

I tried the various recover my account links etc.. all to no avail, I came to the conclusion that I needed to re-import the backup of my workspace, however to do this I needed to delete the broken on my laptop, I couldn’t do this as I couldn’t log in to the workspace… 

So after some digging around I found the following location (this is on Windows 7, if you’re on something older, upgrade!):

C:Users<username>AppDataLocalMicrosoftOfficeGrooveUserAccounts

Under here are some folders with seemingly random names, deleting the folders essentially reset SharePoint Workspace to it’s defaults & allowed me to re-import my backup – note I only had one account configured, if you have more than one you’ll need to find a way to identify which is the one for your broken account – measure twice, cut once!  Doing this will obliterate your account & any data stored locally which means anything not uploaded yet will be lost – this wasn’t an issue for me but be aware of it before you delete the account folder, if it is an issue for you this solution probably isn’t suitable.

Server 2008 AD schema onwards has a very cool feature called fine-grained password policies, these can be a bit arduous to setup, the easiest way that I’ve found to set them up is to create an ldifde answer file and import them using that.  In this example I’m creating a password policy called ServiceAccounts and applying it to the group called ServiceAccounts. 

dn: CN=ServiceAccounts, CN=Password Settings Container,CN=System,DC=robsdesk,DC=com
changetype: add
objectClass: msDS-PasswordSettings
msDS-MaximumPasswordAge:-1728000000000
msDS-MinimumPasswordAge:-864000000000
msDS-MinimumPasswordLength:8
msDS-PasswordHistoryLength:0
msDS-PasswordComplexityEnabled:TRUE
msDS-PasswordReversibleEncryptionEnabled:FALSE
msDS-LockoutObservationWindow:-18000000000
msDS-LockoutDuration:-18000000000
msDS-LockoutThreshold:5
msDS-PasswordSettingsPrecedence:20
msDS-PSOAppliesTo:CN=ServiceAccounts,OU=DomainManagement,DC=robsdesk,DC=com

Execute this command:

Ldifde -i -f pso.ldf

This will create a policy with the following attributes:

• Maximum password age of 2 days
• Minimum password age of 1 day
• Minimum password length of 8 characters
• Password history
• Require complexity
• Store with reversible encryption
• 30 minute lockout observation window
• 30 minute lockout
• Lockout after 5 failures
• Precedence of 20 – like MX records the lowest ‘cost’ comes first.

Make accounts you want to apply the policy to a member of the group.  You can edit the settings in the policy using ADSIEdit by navigating to the Password Settings Container within the System container. 

More detail can be found here: http://technet.microsoft.com/en-us/library/cc770394(WS.10).aspx

Cheers,

Rob

Quick post and run but worth bearing in mind, if you’re doing FBA on TMG & are offloading SSL before the TMG box there’s a reasonable chance that you may not have any certificates installed on your TMG server.  If this is the case users will not be able to change their passwords & those with password must be changed at next login will not be able to log in. 

This is because the TMG server needs to be able to open an LDAPS connection to a DC to do the password change, the S in LDAPS stands for secure, no certificate = not secure.  Install certs, reboot & all is well in the world again.

I’ve recently been engaged on a project where we have multiple web servers (IIS7.5 on 2008r2 for those interested) which require exactly the same content and configuration (they’re sitting behind a Forefront TMG server using a web farm).  The configuration in IIS for this application happens to be complicated & while I have documented how to configure the servers, doing it over and over will not only be tedious but probably introduce some human error. 

To resolve this issue I implemented IIS 7’s shared configuration and put a process in to replicate the content between web servers.

You will need a domain account (or local account on each web server if your web servers aren’t domain joined) which will be used to access the shared configuration (it only does this – your web applications continue to run under what ever application pool identity you have set) and a file share to store the configuration on.

Assuming you’re at the stage of having a configured web server with the IIS configuration how you want it you need to export the configuration:

1. On the first web server / machine which will host the shared configuration create a directory & share it giving full share and ntfs permissions to the service account created, all other permissions should be removed.
2. In IIS manager on the server with IIS configured as per the previous steps click on the server node in the left pane, then open shared configuration in the right pane, then finally select the export configuration option on the right, store the export in the directory created in step 1, entering an encryption key (this should be recorded as it is needed for all nodes which will be accessing the shared configuration).
3. When exported tick the ‘Enable shared configuration’ box, enter the UNC path to the configuration (eg \machinenameiisconfig) enter the username domainserviceaccount and the password for that account, press apply, you will be prompted for the encryption key provided in step 2.
4. Restart the server to apply configuration, then check IIS is still functioning and the IIS manager can be accessed.

The above steps will reconfigured your already configured web server to work from the shared configuration, now we need to replicate the web content and configure all other web servers to work from the same configuration.

There are several ways of replicating the physical content, DFSR is one option, however I chose not to use it as the content on the web servers is staying static so frequent updates to the other nodes will not be required and it gives the operator responsible for the servers more control over how content updates are deployed.  So instead I used robocopy (which has been built in since Vista / Server 2008) to mirror the content from the configured server to all others (this was executed on the web server to be copied to):

robocopy \configuredwebserverc$inetpubwwwroot c:inetpubwwwroot /MIR

Once the file content was in place two quick steps are required to configure IIS to use the shared configuration:

1. Open IIS manager, click on the server name in the left pane, then select the shared configuration option in the right pane, tick the ‘Enable shared configuration’ box, enter the UNC path to the configuration as specified on the first web server (eg \machinenameiisconfig) enter the username domainserviceaccount and the password for that account, press apply, you will be prompted for the encryption key.
2. Restart the server to apply configuration, then check IIS is still functioning and the IIS manager can be accessed.

This process will replicate all application pools and IIS configuration, however if you have ODBC data sources etc.. (things external to IIS which your web applications are using) then you will need to find a way to replicate these settings as well. 

An important point is how IIS behaves if the configuration becomes unavailable, under Server 2008 (not R2) if the configuration disappears IIS will essentially stop, under R2 the server will detect this, continue working and reconnect when the configuration source comes back online.  You can enable offline files for added resiliency should you require it.