Pages

Wednesday, August 25, 2010

Testing Exchange 2007 or 2010 hub transport server email delivery with an email with an attachment

I believe most Exchange professionals out there already know about the way of testing Exchange 2007 or 2010’s hub transport server’s delivery by simply creating an email file and dropping it into the C:\Program Files\Microsoft\Exchange Server\TransportRoles\Pickup folder for delivery but there was this one day when I was asked the following question:

Ok, so we both know how to test mail delivery with the eml file but we’re currently experiencing complaints from the client that the automatically generated emails with those reports are taking too long to get to them. Terence, do you know how we can include an attachment to test?

I didn’t know the answer and since I ended up proving that it wasn’t our Exchange that was causing the delays in delivery, I never spent the time to figure it out. After having this “to-do” list linger in my mind, I finally asked the question on our Partner Support Forums and it’s actually quite simple:

  1. Open Outlook Express.
  2. Create an email.
  3. Add content to email.
  4. Save file as eml.
  5. Drop file as we usually do into the pickup folder.

The instructions made me ask myself: “Why didn’t I think about that?”

I like to give credit to where credit is due so let me thank Bob Huang from our Partner Support for this.

Now to add some value to this post, let me include the issues while trying to get this to successfully work:

Step 1 – Create the email in Outlook Express

image

Step 2 – Save file as someFile.eml

image

Step 3 – Drop the file into the C:\Program Files\Microsoft\Exchange Server\TransportRoles\Pickup folder for delivery.

image

Step 4 – Looks good so far

image

Step 5 – It appears Exchange doesn’t like this file seeing how it renamed it to “.bad”.

image

Let’s delete it and look at the content.

Step 6 – Content of the EML file

image

To: "tluk@unislumin.com"
Subject: Testing EML w/attachment delivered via Pickup Folder
Date: Wed, 25 Aug 2010 10:30:41 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000A_01CB4440.A2AA0C00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Unsent: 1
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_000B_01CB4440.A2AA0C00"

------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Testing
------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18928">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Testing</FONT></DIV></BODY></HTML>

------=_NextPart_001_000B_01CB4440.A2AA0C00--

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: text/plain;
name="Test Attachment.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Test Attachment.txt"

Some text.
------=_NextPart_000_000A_01CB4440.A2AA0C00--

Step 5 – Analyzing content

The first problem I see is that there is no From line indicating where this mail is from so let’s modify the text to:

From: "tluk@unislumin.com"
To: "tluk@unislumin.com"
Subject: Testing EML w/attachment delivered via Pickup Folder
Date: Wed, 25 Aug 2010 10:30:41 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000A_01CB4440.A2AA0C00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Unsent: 1
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_000B_01CB4440.A2AA0C00"

------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Testing
------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18928">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Testing</FONT></DIV></BODY></HTML>

------=_NextPart_001_000B_01CB4440.A2AA0C00--

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: text/plain;
name="Test Attachment.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Test Attachment.txt"

Some text.
------=_NextPart_000_000A_01CB4440.A2AA0C00--

Step 6 – Looks like Exchange still doesn’t like it

image

Step 7 – Reviewing the file again, I went ahead and removed the quotes from the “From” and the “To”.

From: tluk@unislumin.com
To: tluk@unislumin.com
Subject: Testing EML w/attachment delivered via Pickup Folder
Date: Wed, 25 Aug 2010 10:30:41 -0400
MIME-Version: 1.0
Content-Type: multipart/mixed;
boundary="----=_NextPart_000_000A_01CB4440.A2AA0C00"
X-Priority: 3
X-MSMail-Priority: Normal
X-Unsent: 1
X-MimeOLE: Produced By Microsoft MimeOLE V6.00.2900.5931

This is a multi-part message in MIME format.

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: multipart/alternative;
boundary="----=_NextPart_001_000B_01CB4440.A2AA0C00"

------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/plain;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

Testing
------=_NextPart_001_000B_01CB4440.A2AA0C00
Content-Type: text/html;
charset="iso-8859-1"
Content-Transfer-Encoding: quoted-printable

<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.0 Transitional//EN">
<HTML><HEAD>
<META content=3D"text/html; charset=3Diso-8859-1" =
http-equiv=3DContent-Type>
<META name=3DGENERATOR content=3D"MSHTML 8.00.6001.18928">
<STYLE></STYLE>
</HEAD>
<BODY bgColor=3D#ffffff>
<DIV><FONT size=3D2 face=3DArial>Testing</FONT></DIV></BODY></HTML>

------=_NextPart_001_000B_01CB4440.A2AA0C00--

------=_NextPart_000_000A_01CB4440.A2AA0C00
Content-Type: text/plain;
name="Test Attachment.txt"
Content-Transfer-Encoding: 7bit
Content-Disposition: attachment;
filename="Test Attachment.txt"

Some text.
------=_NextPart_000_000A_01CB4440.A2AA0C00--

Step 8 – This time Exchange successfully delivers the message.

image

image

image

========================================================

So now some of you might ask: “Do I have to use Outlook Express because I don’t see an eml option in Outlook?”

I asked myself that question as well because the options I saw while trying to save an email in Outlook were:

Txt, OFT, MSG, HTM, HTML, MHT.

image

I don’t have the answer yet but I did ask Bob about this and will update this post when I get an answer.

I hope this helps someone out there that comes across this and needs to test Exchange with attachments.

Update

I got an answer back from Microsoft and it looks like Outlook cannot save messages in the EML format and this is by design. As a workaround, they suggested to use 3rd party converters such as the following:

http://bitdaddys.com/outlookEMLandMSGconverter.html

http://www.fileguru.com/apps/convert_msg_to_eml

Tuesday, August 24, 2010

Microsoft Office Communicator client consistently crashing when making or receiving audio calls

Problem

Ran into an interesting problem at an engineering company after deploying IM and Presence 2 months ago for them. Enterprise voice has not been deployed yet (this project just kicked off yesterday), so users have been using communicator calls to other coworkers. A small number of the 30 or so users who were in the pilot began reporting that their MOC client would crash when making or receiving audio calls. The recommendations we found through the research done on the internet and the information we got back from Microsoft was that we needed to update the MOC client with the latest patch but all of the users were already using the latest patch available from May 2010. The IT analyst here has 1 desktop and 1 laptop and while his desktop constantly crashes, his laptop doesn’t.

What’s strange is that there was a user who had no problems in the Toronto office but started experiencing issues after she moved to the Ottawa office which was on a different subnet. The voice calls from Toronto would crash but not locally in Ottawa office so a test was done from a desktop on same subnet with another laptop, the first call worked but when tried from different computer, it would crash.

After reaching out to a support engineer from the Microsoft Partner Support Forum, a recommendation to use Process Explorer from SysInternals to try and figure out what service might be causing MOC to crash. After doing a bit of poking around, we originally thought it was the iTune service but later discovered that it wasn’t.

Resolution

Long story short, the problem ended up being an application called NetSupport that was used for managing desktops. This application had a hook into the audio and video which would explain why MOC would crash upon receiving calls.

The version that caused the MOC client to crash was NetSupport for Windows 32 bit Client 10.60.6. Once we updated it to version 11.00.2, the problem went away:

image

I’m sure this will help me in the future when I’m troubleshooting this type of issue as I’ll always be on a lookout for any applications running in the background that may have a hook on the audio and video of a desktop/laptop.

Friday, August 20, 2010

Transferring calls from Exchange UM AA or OCS to PBX - Incoming Caller ID Matters

This problem is similar to the problem in my previous blog post: Transferring calls from Exchange UM AA or OCS to PBX - Gateway Passed # Matters found here: http://terenceluk.blogspot.com/2010/08/transferring-calls-from-exchange-um-aa.html

Problem – External user calls in via PSTN with a blocked number

Call Flow

External PSTN call comes in with the caller ID blocked. The blocked caller ID is passed to the gateway as blank.

Cisco 2801 Gateway receives the PSTN call with the caller ID blocked and pass it to the mediation server with a blank caller ID.

Mediation server passes the number to OCS as: mailto:anonymous@domain.com

OCS server passes the number to Exchange UM AA as: mailto:anonymous@domain.com

Dial by extension is selected and the extension dialed is: 291

Number is translated to: +5492 (user’s DID)

Call fails with: ms-diagnostics: 1022;reason="Cannot process routing destination";source="SomeServer-OCS01.inside.domain.com";Destination="mailto:phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone"

------------EndOfIncoming SipMessage

The following screenshot of the snooper logs show the inbound call:

image

Important strings found in the logs:

1. INVITE sip:+800@10.10.10.2:5060 SIP/2.0

2. FROM: "anonymous" <sip:anonymous@10.10.10.1>;tag=104C61A8-828

3. TO: <sip:+800@10.10.10.2>

4. ms-diagnostics: 1022;reason="Cannot process routing destination";source="SomeServer-OCS01.inside.domain.com";Destination="mailto:phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone"

5. ------------EndOfIncoming SipMessage

As shown in the above strings, while the TO field has an address with a +xxx number, the FROM field is now set to anonymous.

Carefully reviewing the logs show that the call flow ends up as described in the following:

1. AA is represented as +800 with the gateway translating the external number of 6095 to +800 to get pass the other problem with the TO field as number without a +.

2. Cisco 2801 Gateway receives the PSTN number as 6095 and passes it to the mediation server as +800. However, the FROM field now has an address of sip:anonymous@10.10.10.1. The logs show the following entries:

INVITE sip:+800@10.10.10.2:5060 SIP/2.0

FROM: "anonymous" <sip:anonymous@10.10.10.1>;tag=104C61A8-828

TO: <sip:+800@10.10.10.2>

**Where 10.10.10.2 is the mediation server and 10.10.10.1 is the Cisco 2801 gateway.

image

3. Mediation server passes the number to OCS as 6095. The log shows the following entries:

TL_INFO(TF_PROTOCOL) [2]085C.0E44::01/15/2010-20:57:03.444.00010246 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(531))

>>>>>>>>>>>>Outgoing SipMessage c=[<SipTlsConnection_12212D0>], 192.168.1.116:50184->192.168.1.115:5061

INVITE mailto:+800@domain.com;user=phone SIP/2.0

FROM: "anonymous"<sip:anonymous@domain.com;user=phone>;epid=F9C5342898;tag=70b9ddd639

TO: <sip:+800@domain.com;user=phone>

image

4. OCS signals Exchange UM and the mediation server passes the number to Exchange UM AA as +800 with a FROM address as sip:anonymous@10.10.10.2. The log shows the following entries:

TL_INFO(TF_PROTOCOL) [5]085C.0E38::01/15/2010-20:57:04.179.00010430 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(581))

<<<<<<<<<<<<Incoming SipMessage c=[<SipTlsConnection_12212D0>], 192.168.1.116:50184<-192.168.1.115:5061

SIP/2.0 200 OK

FROM: "anonymous"<sip:anonymous@domain.com;user=phone>;tag=70b9ddd639;epid=F9C5342898

TO: <sip:+800@domain.com;user=phone>;epid=7F0379AFD1;tag=aefea27dc

CSEQ: 134 INVITE

CALL-ID: 87ec3f0c-0e4c-4d9e-ba6e-81fa3c946e34

VIA: SIP/2.0/TLS 192.168.1.116:50184;branch=z9hG4bKffeb327d;ms-received-port=50184;ms-received-cid=34B00

RECORD-ROUTE: <sip:SomeServer-OCS01.inside.domain.com:5061;transport=tls;opaque=state:T;lr>

CONTACT: <sip:SomeServer-UM01.inside.domain.com:5066;transport=Tls>;automata

image

5. Dial by extension is selected and the extension dialed is 291. The log shows the following entries:

REFER-TO: <mailto:phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone>

image

6. The dialed extension 419 doesn’t even make it to the normalization rule that is supposed to translate it to a 4-digit DID and fails with a SIP/2.0 504 Server time-out. The log shows the following entries:

SIP/2.0 504 Server time-out

FROM: "anonymous"<sip:anonymous@domain.com;user=phone>;epid=F9C5342898;tag=97c5974872

TO: <sip:419;phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone>;tag=81D2DBAF0A35A006E2070899EC12AB7C

CSEQ: 135 INVITE

CALL-ID: baf77a8d-3a58-42b5-8abf-a13b7523b836

VIA: SIP/2.0/TLS 192.168.1.116:50185;branch=z9hG4bK1499847;ms-received-port=50185;ms-received-cid=34E00

CONTENT-LENGTH: 0

ms-diagnostics: 1022;reason="Cannot process routing destination";source="SomeServer-OCS01.inside.domain.com";Destination="sip:419;phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone"

------------EndOfIncoming SipMessage

**Note that the error here shows: Destination="mailto:phone-context=Toronto.inside.domain.com@192.168.1.115;user=phone"

If the call is successfully routed, the @192.168.1.115;user=phone should be replaced with dialplan.domain.com@ForestFQDN.

image

Resolution

The resolution for this problem was to have the gateway send rewrite all calls coming in from the PSTN with a blocked caller ID to a bogus number. In our case, we rewrote it to +4165555555 thus rendering the FROM sip address as:

FROM: "anonymous" <sip:+4165555555@10.10.10.1>;tag=24FE0010-8CA

The initial connection for the call would look like this:

INVITE sip:+800@10.10.10.2:5060 SIP/2.0

FROM: "anonymous" <sip:+4165555555@10.10.10.1>;tag=24FE0010-8CA

TO: <sip:+800@10.10.10.2>

The log shows the following entries during the successful transfer:

TL_INFO(TF_PROTOCOL) [5]085C.0E38::01/19/2010-21:23:14.411.00011679 (S4,SipMessage.DataLoggingHelper:sipmessage.cs(581))

<<<<<<<<<<<<Incoming SipMessage c=[<SipTcpConnection_3FF2357>], 10.10.10.2:5060<-10.10.10.1:58223

INVITE sip:+800@10.10.10.2:5060 SIP/2.0

FROM: "anonymous" <sip:+4165555555@10.10.10.1>;tag=24FE54A4-2029

TO: <sip:+800@10.10.10.2>

CSEQ: 101 INVITE

CALL-ID: F1944E13-47711DF-9C05FA5F-32802FEB@10.10.10.1

MAX-FORWARDS: 70

VIA: SIP/2.0/TCP 10.10.10.1:5060;branch=z9hG4bK3191DF

ALLOW-EVENTS: telephone-event

CONTACT: <sip:anonymous@10.10.10.1:5060;transport=tcp>

image

Reviewing the snooper trace logs, the FROM field is now rewritten with sip:+4165555555.

image

Here is a side-by-side snooper logs with a failed and a successful call with a blocked ID and a valid caller ID:

image

Note that this problem isn’t specific to AA. If a user dials an OCS user’s direct line bypassing the AA with a blocked ID, when the OCS user tries to transfer the call over to the BCM, the transfer will fail. There aren’t any issues if the OCS user transfers to another OCS user though.

I’m anxious to test this out when CS 14 RTMs.

VMware vCenter Update Manager – “Database temporarily unavailable or has network problems.”

While the following message can be caused by many reasons, I thought I’d list the one I encountered a few months back while deploying VUM.

Error Message:

There was an error connecting to VMware vCenter Update Manager - [serverName.domain.com: 8084].

Database temporarily unavailable or has network problems.

image

In my case, it was caused by service not running as the proper service account that has access to the database.

image

Once I changed the account to the proper service account that had access to the VUM database, the error message went away.

Thursday, August 19, 2010

Transferring calls from Exchange UM AA or OCS to PBX - Gateway Passed # Matters

Here’s another interesting problem I came across awhile ago. During New Orleans TechEd and CS 14 training, I actually asked the Microsoft representatives about manipulating SIP addresses and REFER fields and got different answers. From New Orleans, they said that there’s more control and might be able to modify them but from CS 14 training in Arizona, I was told by one of the MCS consultants who was also a trainer that this cannot be done. Since CS 14 is still in beta refresh right now, I’m going to wait till it comes out to do some testing:

Problem – DID passed to AA without a “+”

Call Flow

External PSTN number mapped to AA: 6095

Cisco 2801 Gateway receives the PSTN number and passes it to the mediation server as: 6095

Mediation server passes the number to OCS as: 6095

OCS server passes the number to Exchange UM AA as: 6095

Dial by extension is selected and the extension dialed is: 291

Number is translated to: +5492 (user’s DID)

Call fails with: ms-diagnostics: 1003;reason="User does not exist";source="SomeServer-OCS01.inside.domain.com";TargetUri="+5492@domain.com"

The following screenshot of the snooper logs show the inbound call:

image

Important strings found in the logs:

1. FROM: mailto:+2892596319@domain.com;user=phone

2. TO: mailto:phone-context=Toronto.inside.domain.com@domain.com;user=phone

3. ms-diagnostics: 1003;reason="User does not exist";source="SomeServer-OCS01.inside.domain.com";TargetUri=+5492@domain.com

Carefully reviewing the logs show that the call flow ends up as described in the following:

1. AA is represented as 416-xxx-6095 externally.

2. Cisco 2801 Gateway receives the PSTN number as 6095 and passes it to the mediation server as 6095. The logs show the following entries:

INVITE sip:6095@10.10.10.2:5060 SIP/2.0

FROM: <sip:+289XXX6319@10.10.10.1>;tag=5A74AC0-1F39

TO: <sip:6095@10.10.10.2>

**Where 10.10.10.2 is the mediation server and 10.10.10.1 is the Cisco 2801 gateway.

image

3. Mediation server passes the number to OCS as 6095. The log shows the following entries:

Outgoing SipMessage c=[<SipTlsConnection_19408CD>], 192.168.1.116:50867->192.168.1.115:5061

FROM: ""<sip:+289xxx6319@domain.com;user=phone>;epid=F58B7DF87F;tag=fc93a58819

TO: <sip:6095;phone-context=Toronto.inside.domain.com@domain.com;user=phone>

image

4. OCS signals Exchange UM and the mediation server passes the number to Exchange UM AA as 6095. The log shows the following entries:

<<<<<<<<<<<<Incoming SipMessage c=[<SipTlsConnection_19408CD>], 192.168.1.116:50867<-192.168.1.115:5061

CONTACT: <sip:SomeServer-UM01.inside.domain.com:5066;transport=Tls>;automata

FROM: ""<sip:+289xxx6319@domain.com;user=phone>;epid=F58B7DF87F;tag=fc93a58819

TO: <sip:6095;phone-context=Toronto.inside.domain.com@domain.com;user=phone>

image

5. Dial by extension is selected and the extension dialed is 291. The log shows the following entries:

REFER-TO: <mailto:phone-context=Toronto.inside.domain.com@domain.com;user=phone>

FROM: 6095;phone-context

FROM: sip+2892596319…

image

6. Number is translated to +5492 (user’s DID). The log shows the following entries:

ms-diagnostics: 14011;reason="Called Number translated";source="SomeServer-OCS01.inside.domain.com";RuleName="291 to +5492";RuleDN="CN={3191FB78-32F6-4328-9538-AB608F295191},CN=Location Normalization Rules,CN=RTC Service,CN=Services,CN=Configuration,DC=inside,DC=domain,DC=com";CalledNumber="291";TranslatedNumber="+5492";appName="TranslationService"

------------EndOfIncoming SipMessage

image

7. The call gets sent from Exchange AA to OCS Front-End, then from OCS Front-End to Mediation, then back to OCS Front-End. The call finally fails with:

ms-diagnostics: 1003;reason="User does not exist";source="Domain-OCS01.inside.domain.com";TargetUri=+5492@domain.com

image

Resolution

The resolution for this problem was to have the gateway send the 6095 as +6095 thus rendering the sip address as:

TO: mailto:phone-context=Toronto.inside.domain.com@domain.com;user=phone

The log shows the following entries during the successful transfer:

INVITE mailto:+5492@SomeServer-MED01.inside.domain.com:5061;user=phone;maddr=SomeServer-MED01.inside.domain.com SIP/2.0

FROM: ""<sip:+2892596319@domain.com;user=phone>;epid=F58B7DF87F;tag=3677ff378a

TO: <sip:291;phone-context=Toronto.inside.domain.com@domain.com;user=phone>

image

Reviewing the snooper trace logs, the TO field is now populated with sip:+6095@10.10.10.2 with the +6095.

image

Note: Please let me know if some of the screenshots don’t appear to match with the description as I may have made some mistakes copying and pasting the images when I had to blank out the domain names. Thanks.

------------------------------------------------------------------------

I happened to talk about this problem I encountered with our Cisco UC practice lead awhile ago and he asked me to present this to our consultants so I ended up creating a PowerPoint presentation:

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

image

I will try to find some time to write up a post about a similar problem we had with anonymous calls.

Wednesday, August 18, 2010

Auto Attendant Transfer to BCM Extension Problem / Resolution - Active Directory Telephone Attribute Matters

I ran into an interesting issue while integrating Exchange Unified Messaging’s Auto Attendant with OCS and PBX. After setting up everyone who was still living on the BCM’s EUM attribute to include the following string:

xxx;phone-context=LocationProfile.domain.com

… I noticed that when I called into AA, hit option # to transfer to a user’s extension, then entered someone who was on the BCM, I would get transferred to reception. After proceeding to test with another user I’ve been testing with, I noticed that I didn’t have any problems with the user. Just to be safe, I went ahead and opened up both of their mailbox attributes to confirm that their E-Mail Addresses tab was correct and they were:

image

Since I was running out of ideas, I went ahead and turned on logging on both the front-end and mediation server. After carefully reviewing the mediation server logs, I noticed something different about calling into extension 278 and extension 291:

image

As shown in the screenshot above, we can clearly see that after the NOTIFY sip:SomeName-UM01.inside.domain.com line, the successful transfer for extension 291 has an INVITE sip:291;phone-context=Toronto.inside.domain.com while the failed extension 278 shows INVITE sip:4165555555;phone-context=Toronto.inside.domain.com.

As I continued to scratch my head, I thought it was worth reviewing all the attributes stored in the Active Directory Users and Computers MMC snap-in. Opening the 2 users’ AD attributes window side by side shows the following:

image

I didn’t think the Telephone number attribute mattered but figure I’d give it a shot by changing Melvin’s to his internal extension as 278.

I went ahead and called in Exchange UM’s AA, hit # for transfer to user’s extension, and finally 278. The call successfully transfers! As it turns out, Exchange AA actually uses the EUM attribute to ensure that the extension that exist but when the call is actually transferred, it’s transferred via the user’s AD Telephone number attribute. I’ve also taken the time to confirm that this is true by entering my cell phone’s PSTN number in the telephone field, make an attempt to transfer and my cell phone ended up ringing.

I posted the snooper logs internally but can’t do it here as there’s the client’s company domain name in them.

Tuesday, August 17, 2010

Event ID: 5719, 29 Error and Event ID: 14 Warnings being logged after reboot of Windows Server

This was a problem I ran into during an OCS deployment at a client and what was interesting was that I didn’t end up solving the issue even though I knew what has happening within Windows. This client was an international engineering company with a manager who has engineering discipline that was very technical from a networking perspective so he ended up solving this during one of his management meetings. I still tease him up to this day about not paying attention during his meeting.

Problem

The following errors are logged:

Event ID: 5719 - Error

This computer was not able to set up a secure session with a domain controller in domain GENNUM due to the following:

There are currently no logon servers available to service the logon request.

This may lead to authentication problems. Make sure that this computer is connected to the network. If the problem persists, please contact your domain administrator.

ADDITIONAL INFO

If this computer is a domain controller for the specified domain, it sets up the secure session to the primary domain controller emulator in the specified domain. Otherwise, this computer sets up the secure session to any domain controller in the specified domain.

For more information, see Help and Support Center….

------------------------------------------------------------------------------------------------------------------------

Event ID: 14 - Warning

The time provider NtpClient was unable to find a domain controller to use as a time source. NtpClient will try again in 15 minutes.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

------------------------------------------------------------------------------------------------------------------------

Event ID: 29 - Error

The time provider NtpClient is configured to acquire time from one or more time sources, however none of the sources are currently accessible. No attempt to contact a source will be made for 15 minutes. NtpClient has no source of accurate time.

For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp.

------------------------------------------------------------------------------------------------------------------------

Resolution

Through reviewing these logs and thinking the process through, it was obvious that upon bootup, the server wasn’t able to contact the domain controllers immediately and so caused these errors to get logged. In most cases, this wasn’t a problem because the server would be able to communicate to a domain controller a bit later but in this case, it caused the OCS services to fail on startup. While doing research, I found a few KB articles from Microsoft that hinted about NIC issues and suggested to upgrade the drivers which I don’t think was the issue. I also started logging onto other servers within the environment and noticed that all of the servers exhibited the same problem. After explaining the issue to the manager and asked him about the switches, he came back to me a few hours later, told me to try rebooting the server again and when I reviewed the logs, these errors and warnings were gone. The resolution was simple:

Spanning tree disabled or enable faststart (for Cisco).