Monday, September 13, 2010

Sunday, September 12, 2010

Microsoft "Lync 2010" and "Lync Server 2010"?

http://www.microsoft.com/downloads/en/details.aspx?FamilyID=1772A5AD-9688-4861-8387-EC30411BF455

Now when you read the above link information it's clear that a product called "Microsoft Lync Server 2010" is on it's way. What could this be? I'll give you a hint....check the Microsoft web site tomorrow (September 13th, 2010).

UPDATE 1: If you type in www.microsoft.com/lync it points you to a web page (but with an error): http://www.microsoft.com/en-us/lync/default.aspx

UPDATE 2: It's official! Microsoft Lync 2010 is now on the web site http://www.microsoft.com/lync

Cheers!

Saturday, September 4, 2010

Outlook profiles don't update when you move a mailbox (Exchange 2010)

So consider this....

You're performing a migration from a previous version of Exchange Server to the new 2010 platform. You move a mailbox, the person opens Outlook and poof......the profile gets updated. Now let's say the server you've just migrated the account to is an Exchange 2010 all-in-one (hub/mb/cas) server and you move the mailbox to another all-in-one server in a different site. No problem right? Well in the words of a well known Kazakhstan wiseman.......not so much!

Here's the problem. Your Outlook clients will NEVER update their profiles again as long as they can reach the Exchange 2010 CAS role they were moved to originally. This applies to all current Outlook clients including Outlook 2010!

So here's my story:
We were working on a client project where we completed a cross-forest migration from Exchange 2003 to 2010. We built a 3 server all-in-one Exchange 2010 in Canada which would eventually be the final location of the USA mailboxes. To make the move from the USA to Canada possible we set up a local Exchange 2010 server first. This allowed us to perform a cross-forest move locally first, then an online mailbox move over time. The online mailbox move feature in Exchange 2010 worked great. We used the "-SuspendWhenReadyToComplete" switch so we wouldn't interfere with end user connections and resumed the move request at night which flipped the mailbox over. Well we didn't get far before someone noticed Outlook wasn't pointed at the new environment in Canada.

Prior to the migration of any data, we set up our CAS Array in Canada and made sure the RpcClientAccessServer property of each database in the DAG pointed to the new FQDN we created. One would think the Outlook client would check this attribute on first connect to see which CAS server they should connect to but it does not.

Here are a couple ideas to resolve this issue which failed:

1. Running a script to update the Outlook profile using a ".prf" file. Unfortunately this causes the Outlook client running in cached mode to re-cache their mailbox. For an organization with slow WAN links and large mailboxes this can be disastrous. No dice.

2. Create a host entry on the servers in Canada pointing them to the IP of the USA server then updating the DNS record used by clients to have them point to the CAS array. This was less desirable due to the 'jiggery pokery' of meddling with DNS. It didn't work anyway...

3. Disable MAPI clients for a user using "Set-CasMailbox -identity -MAPIEnabled:$false". Have the user launch Outlook. Enable MAPI. Done! That worked.....but impossible to do for several hundred users individually.

I contacted a few Microsoft Exchange team individuals and quickly found out there was only one way to fix this. For Outlook 2003 clients you need to update the profile manually or run a PRF file to update it (causing a re-sync of the OST). For Outlook 2007/2010 clients, a "Repair" of the profile will cause it to wake up and talk to the right server.

So here we have it. Not the greatest solution. We currently have a high severity case open with Microsoft on the issue (as do others). I'll update my post as I know more.

Crap.

Wednesday, September 1, 2010

Communications Server 14 Voodoo (Aastra phones)

I come across these interesting tidbits which I like to share with the 800 or so visitors I get weekly.

Aastra sent me a pair of IP phones to help with a customer demo and I've had a few issues setting them up. I suppose it helps if you read the #$@#$ manual but working with beta software/hardware doesn't always yield the same easy to read, or readily available docs.



Anyway, here are a few tidbits to help you along the way:

DHCPUtil.exe: This utility will help you configure your DHCP options for the Aries (Wave 14) IP phones. You need to configure several new DHCP options in order for the phone to work properly. You will find this utility in the \support folder of your W14 media. Using the following syntax, the utility will configure the options for you (highly recommended): DHCPUtil.exe -sipserver -webserver -RunConfigScript

NOTE: You need to run the above utility on your Windows DHCP server. If it's not an x64 OS, you need to install the "vcredist_x86" from the W14 media.

How to do a hard reset: Hold down the "#" + "4" + backspace keys and plug in the phone. Keep them held down until you see a screen asking if you want to reset the phone.

How to test the phone's bootstrap process: On your Communications Server front-end server, open PowerShell and run: "Test-CsPhoneBootStrap -PhoneOrExt -PIN .

Cheers.