Karsten Palmvig's blog : Troubleshooting

Troubleshoot: CWA publishSelfPresence request error

kpalmvig — Thu, 01 Oct 2009 13:52:00 GMT

If you encounter the publishSelfPresence request error (Error Code = 0-1-492) in the CWA client, you most likely have a problem with the SPN (Service Principal Name) of the CWA Service Account.

To correct this problem; open AdsiEdit and navigate to the CWA Service Account, right click and select Properties.

Scroll down to the servicePrincipalName attribute. The SPN must contain the host name that users are connecting to as well as the physical server. In many scenarios CWA is published as cwa.domain.com while the actual host name may be something like ocscwasrv01.domain.com.

Double click the servicePrincipalName attribute to edit it and make sure both names are registered like this:

http/cwa.domain.com
http/ocscwasrv01.domain.com

Note the single slash, do not type the address as “http://” – and replace host names and domain with your actual values.

Troubleshoot: Cannot complete certificate request in IIS 7

kpalmvig — Tue, 22 Sep 2009 23:29:04 GMT

When trying to complete a certificate request in IIS 7 you may experience the error:

CertEnroll::CX509Enrollment::p_InstallResponse: ASN1 bad tag value met. 0x8009310b (ASN:276)

This error is described in KB article 959216 but the suggested resolution may not apply to you as the certificate is not imported into the certificate store regardless of the error message as the article describes.

To mitigate this (at least with GoDaddy certificates but it may apply to others), submit a new certificate request from within IIS 7 and log on to the certificate providers website and select re-key for the problematic certificate. Download the re-keyed certificate and select “Complete Certificate Request” in IIS 7, select the .crt or .cer file and supply the friendly name for the certificate.

Hopefully you now have your certificate in the Local Computer\Personal store. Don’t forget to export your certificate with private key and store it in a safe place.

HTH

Troubleshoot: Office Communicator problem verifying certificate

kpalmvig — Wed, 07 Jan 2009 20:38:49 GMT

You encounter the following error when trying to connect to the pool with Office Communicator:

This is caused by the certificate on the server not matching the host name you are trying to connect to. Typically this is because the _sipinternaltls SRV record in DNS is pointing to a physical OCS server instead of the pool name and the certificate on the server is (rightfully) issued for the pool name.

Adding Subject Alternate Names in the certificate for the physical server(s) is not the right approach to solve this issue.

After correcting the SRV record, remember to flush the DNS cache on the client.

Troubleshoot: Why are call notifications and voice mails not showing on my Tanjay?

kpalmvig — Sun, 20 Jan 2008 12:08:27 GMT

If you have a Office Communicator Phone Edition (aka. Tanjay) device, you might be wondering why your incoming, outgoing and missed calls as well as voice mails are not showing up in the lists on the device.

For the integration to work, the Tanjay needs to access your mailbox and for this to work it needs to be able to resolve the autodiscover.domain.ext for your domain to an internal server.

So make sure you have published your autodiscover properly in your internal DNS, mapping to your Client Access Server(s).

The Exchange 2007 Client Access Server(s) hosting the Autodiscover service must have the autodiscover.domain.ext as a SAN (Subject Alternate Name) in the certificate assigned to the web site hosting the Autodiscover service.

(Refer to my post on voice mails not submitted to HUB Transport to see syntax for requesting a certificate with SAN's)

Restart the Tanjay for it to pick up the changes faster.

Bonus information: To play voice mails on your Tanjay; VoIP security on your Exchange 2007 UM Dial Plan must be set to "Secured".

Troubleshoot: UM voice mails not submitted to Hub Transport

kpalmvig — Thu, 27 Dec 2007 01:19:00 GMT

After you have set up the Exchange Server 2007 UM role in a lab or in production and want to test Auto Attendant functionality by leaving voice mails for one or more users, you may experience that the Auto Attendant plays the greeting and asks for your message but the user doesn't receive anything although everything seems fine.

Voice mails are in fact recorded and will queue up in this directory: C:\Program Files\Microsoft\Exchange Server\UnifiedMessaging\voicemail

This situation can be identified by the following warning in the Application Event log:

Event Type:      Warning
Event Source:    MSExchange Unified Messaging
Event Category: UMCore
Event ID:        1185
Date:            17-12-2007
Time:            16:32:06
User:            N/A
Computer:        <Servername>
Description:
The Unified Messaging server was unable to submit a message to Hub Transport server "<Servername>" because the following error occurred: The Unified Messaging server failed to authenticate to the SMTP server: The specified target is unknown or unreachable.

There can be multiple reasons for this, some of these are listed below.

SPN's

If Service Principal Names (SPN) are not registered correctly for your Hub Transport Servers SMTP service, the UM service may fail to identify a usable receive connector and fail to deliver the voice mail.

One scenario where SPN's are registered incorrectly is if receive connectors have been installed on multiple servers (e.g. if the Exchange Organization used to be Exchange Server 2003 and mailboxes and services were migrated to Exchange Server 2007).

To verify that local SPN registration is correct, first run:

setspn -L <Servername>

This will list the locally registered SPN's, there should be only two "SmtpSvc" SPN's:

SmtpSvc/SERVER
SmtpSvc/server.domain.ext

The more likely situation is that another server that no longer has a receive connector installed still have a "SmtpSvc" SPN registered.

To search Active Directory for orphan SPN's, use LDP; connect and bind to AD and press Ctrl-S for the search dialog.

Base Dn: DC=domain,DC=ext
Filter: servicePrincipalName=smtpsvc*

This will result in a list like this:

Getting 2 entries:
>> Dn: CN=OLDSERVER,CN=Computers,DC=domain,DC=ext
    5> objectClass: top; person; organizationalPerson; user; computer;
    1> cn: OLDSERVER;
    1> distinguishedName: CN=OLDSERVER,CN=Computers,DC=domain,DC=ext;
    1> name: OLDSERVER;
    1> canonicalName: domain.ext/Computers/OLDSERVER;
>> Dn: CN=NEWSERVER,CN=Computers,DC=domain,DC=ext
    5> objectClass: top; person; organizationalPerson; user; computer;
    1> cn: NEWSERVER;
    1> distinguishedName: CN=NEWSERVER,CN=Computers,DC=domain,DC=ext;
    1> name: NEWSERVER;
    1> canonicalName: domain.ext/Computers/NEWSERVER;

Now use ldp or adsiedit to further drill down on the OLDSERVER object, I find using adsiedit easier as it allows for instant editing if required. If you're not familiar with editing directly on AD objects, get assistance from someone who is!

List the content of servicePrincipalName and verify that no SmtpSvc entry exists if no SMTP service is running on the machine and verify that only the servers' own name is listed for any SPN.

After removing any faulty SPN registrations; restart the Microsoft Exchange Transport Service on your Hub Transport Server. Then restart Microsoft Exchange Unified Messaging to pick up voice mails in the queue.

Certificates

Exchange UM submits the mails with voice content by using TLS, therefore UM may be unable to authenticate to the receive connector on the Hub Transport Server if the servers use the self signed certificate that Exchange supplies upon installation.

Verify what certificates are installed by running:

Get-ExchangeCertificate | ft services,thumbprint,isselfsigned -auto

The result will look somewhat like this:

                Services Thumbprint                               IsSelfSigned
                -------- ----------                               ------------
IMAP, POP, UM, IIS, SMTP 1234567890ABCDEF1234567890ABCDEF12345678         True

As you can see the only existing certificate is self signed.

Create new certificates for all Exchange Servers in the organization by running this cmdlet:

New-ExchangeCertificate -GenerateRequest -domainname <Server FQDN>, <Server NetBIOS name>[, Server Alias] -FriendlyName <Server FQDN> -privatekeyexportable:$true -keysize 1024 -path c:\certreq.txt

Submit the request file to your internal CA (depending on your Public Key Infrastructure) and save the resulting certificate file as c:\certnew.cer

Then import the certificate by running this cmdlet:

Import-ExchangeCertificate -path c:\certnew.cer | Enable-ExchangeCertificate -services IIS, POP, IMAP, UM, SMTP

Verify again what certificates are installed with Get-ExchangeCertificate.

The result should look like this:

                Services Thumbprint                               IsSelfSigned
                -------- ----------                               ------------
IMAP, POP, UM, IIS, SMTP ABCDEF1234567890ABCDEF1234567890ABFDEF12        False
     IMAP, POP, UM, SMTP 1234567890ABCDEF1234567890ABCDEF12345678         True

As you can see, you now have a non self signed certificate in the certificate store. Remove the self signed certificate by running:

Remove-ExchangeCertificate 1234567890ABCDEF1234567890ABCDEF12345678

Restart Microsoft Exchange Transport and Microsoft Exchange Unified Messaging services and verify if voice mails are delivered.