Microsoft is doing a virtual launch of its new Lync product (OCS replacement) on 17th November.

Stick it in your calendar and go here for all the details:

www.microsoft.com/lync/launch

Extract:

Join us as keynote speakers Chris Capossela, Senior Vice President of the Information Worker Product Management Group at Microsoft, and Gurdeep Singh Pall, Corporate Vice President of the Office Communications Group at Microsoft, discuss how Microsoft Lync can help businesses enhance productivity by delivering a truly integrated communications experience. You can also attend sessions to hear from customers and partners about the value they’re experiencing, participate in live Q&As, blogs, discussions, and more.

If you try and IM a user who is using Exchange 2010 OWA with OCS integration and receive a ‘reference error ID 504’ error then don’t despair.

You will probably find that the user can send IM out but you can’t reply.

The resolution is to simply apply update UcmaRedist.msp on your Exchange 2010 CAS Servers:

http://www.microsoft.com/downloads/en/details.aspx?displaylang=en&FamilyID=b3b02475-150c-41fa-844a-c10a517040f4

Good luck

Regards

Neil

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:\System\CurrentControlSet\services\MSExchangeAB 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:\System\CurrentControlSet\services\MSExchangeRPC 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 domain\user 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:\Windows\system32>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