Pages

Friday, October 25, 2013

I’ve recently been asked at least 5 times over the past 2 months a problem that may seem trivial but at the same time be quite the annoyance. An administrator attempts to change the hostname of a newly deployed ESXi 5.x server via the vSphere client:

… but notices that as soon as they change the name the OK button grays out:

Editing the IP address doesn’t enable the button either.

The answer to this issue is actually quite simple and that is because the Domain field isn’t filled out and while you can change the hostname at the console without entering a domain, the same can’t be done in the vSphere client so to enable the OK button, simply enter a domain:

Definitely one of the more silly issues I’ve heard about over the past few months.

You’re attempting to install Veeam Backup and Replication 7.0 on a new Windows Server 2012 server but noticed that as you go through the install and enter the license file you received from Veeam (veeam_backup_full_0_4.lic), you are unable to proceed past Provide License step because the following error is thrown:

The provided license is not valid.

Removing the license file and installing Veeam as trial completes without any errors so you attempt to install the license by navigating to Help –> License:

Searching through the web didn’t provide me with much information on this error so I went ahead and opened a support call with Veeam. The first response from the engineer was that I may have a Veeam 7 license but I’m installing it into a Veeam 6.5 install but that wasn’t the case so he told me to try opening the license file with notepad to see whether there was actually content in there and to my surprise, there wasn’t. The .lic file was completely blank.

The engineer proceeded to tell me that he has seen a lot of clients downloading the .lic file from webmail (i.e. Exchange OWA) which ends up corrupting the file. I went back to my Outlook 2013 full client to redownload the file on my laptop and quickly saw the content. From there, I copied the .lic file to the server which then installed fine. Strange issue but glad it was a quick fix. One last point I’d like to try and make is that I asked the engineer whether I could just copy the license file contents to the another notepad then save it as a .lic file and he said no because that wouldn’t work. Hope this helps anyone who might come across the same issue.

Thursday, October 24, 2013

You’re setting up an RCC integration between Lync Server 2013 and Avaya’s AES (Application Enablement Services) server and while you’ve set up all of the configuration required for Lync Server 2013, users see a No Phone System Connection error at the bottom of their Lync client:

Clicking on the error displays the following:

Cannot connect to the phone system.

The call control server may be temporarily unavailable. If the problem continues, please contact your support team.

Launching the logging tool on the front end server to perform a trace (S4 and SIP) reveals the following errors:

TL_INFO(TF_PROTOCOL) [0]2268.22EC::09/18/2013-15:27:57.415.004c3c79 (SIPStack,SIPAdminLog::ProtocolRecord::Flush:2436.idx(196))[2906464479] $$begin_recordTrace-Correlation-Id: 2906464479Instance-Id: 322Direction: incomingPeer: aes.contoso.bhl.bm:4723Message-Type: responseSIP/2.0 404 Not found: Session could not be established - no AD record loaded for this userStart-Line: SIP/2.0 404 Not found: Session could not be established - no AD record loaded for this userFrom: "Dowling, James" <sip:jdowling@contoso.bhl.bm>;tag=76adae21b5;epid=ded4b550daTo: <sip:aes@aes.contoso.bhl.bm>Call-ID: e05b19021ca2409f93abeadeff04ab94CSeq: 1 INVITEVia: SIP/2.0/TLS 172.16.1.160:62970;branch=z9hG4bKDFE445FC.559F3707CB33968D;branched=FALSE;rport=62970,SIP/2.0/TLS 172.16.7.6:61597;ms-received-port=61597;ms-received-cid=1900Content-Length: 0$$end_record

Solution

While I’m sure there may be various reasons that would log these errors, the situation I had was actually because the Enterprise Directory information on the Avaya AES server wasn’t filled out:

Once I filled out the information on the AES server, RCC began to work as expected.

… appears quite frequent when searched but none of the solutions fixed my issue. To save others from going through all of the troubleshooting steps I went through myself as well as with a Microsoft support engineer, what ended up fixing my issue was to treat the server as if I’ve lost it and had to perform a recovery install with the:

Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms

… command. There are many articles and blog posts out there demonstrating a recovery install so I’ll just list out the basic steps that I did:

Deploy a new Windows Server 2012 server and don’t join it to the domain

Configure the same drives and letters as the existing Exchange Server 2013

Copy the Exchange databases over to the new server maintaining the same drive and path

Export the public certificate used for OWA and other services to a new server

Document where Exchange is installed (this information can be found via ADSIEdit by navigating to CN=Ex-15,CN=Servers,CN=First Administrative Group,CN=Administrative Groups,CN=First Organization,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=Contoso,CN=Local and opening the CN=EX-15 object then viewing the properties of the msExchInstallPath attribute.

Shutdown the existing Exchange Server 2013 server (we will not start this server back up again so make sure you’ve copied what you need off of it)

Reset the old Exchange server’s computer account

Assign the new Exchange server’s IP to be the same as the problematic one

Change the name of the new server to the problematic Exchange server’s name and restart

Join the new renamed server to the domain

Install the prerequisites for Exchange Server 2013 (the downloaded packages and Roles and Features via PowerShell)

Using the same CU2 package, run the command Setup /m:RecoverServer /IAcceptExchangeServerLicenseTerms

Once the install is complete, restart the server, log into ECP, mount the IS store, reconfigure the virtual directories (i.e. OWA, OAB, etc), review the event logs, then test the services. This fixed the issue I had as the Microsoft engineer suspected that here was some file, handler mapping, or a component that wasn’t functioning properly.

With the solution out of the way, I’m going to include the troubleshooting steps below:

Problem

You have a new Exchange Server 2013 deployment (all roles on the same server) with CU2 installed in the environment and while testing OWA, you notice the following error when you attempt to read the content of an email:

**Sorry about the word wrap but the lines are supposed to look like what is shown in the screenshot.

The output we’re interested in is actually the following:

WebExceptionStatus=ProtocolError;ResponseStatusCode=405;WebException=System.Net.WebException: The remote server returned an error: (405) Method Not Allowed. at System.Net.HttpWebRequest.EndGetResponse(IAsyncResult asyncResult) at Microsoft.Exchange.HttpProxy.ProxyRequestHandler.<>c__DisplayClass20.<OnResponseReady>b__1e();

To fix the error in the logs, perform the following:

Prior to making any changes to IIS, it is recommended to use the following command to backup the site settings first:

It was unfortunate that after 6 hours on a call with Microsoft, the engineer wasn’t able to fix it but I did appreciate the effort he put in. Hope this helps anyone out there who may come across such an issue.

Saturday, October 19, 2013

You have several remote users who are trying to set up their Outlook via the Outlook Anywhere service using Autodiscover to detect the settings but all of them are continuously prompted for their password. The process looks similar to the following:

You enter the appropriate information:

The wizard proceeds to use the autodiscover service to set up the mailbox:

The user then receives a password prompt:

The user proceeds to type in their password but continuously gets prompted as shown above and after 3 or 4 attempts, the user is presented with the following:

An encrypted connection to your mail server is not available.

Click Next to attempt using an unencrypted connection.

Solution

Assuming your autodiscover service is set up appropriately and verified with the Microsoft Remote Connectivity Analyzer (https://testconnectivity.microsoft.com/) tool, this issue may be because your internal domain is different than your external SMTP domain. In this example, the external SMTP domain is <someDomain>.com but the internal domain is <someDomain>.local. This means that the user’s default UPN login is actually <username>.<someDomain>.local and not <username>.<someDomain>.com. If we look closing to the default login username presented to the user, we will see that it has defaulted to the user’s email address which is not a valid login for the user:

One of the workarounds in this situation is to add a new UPN suffix to the domain with the external domain in Active Directory Domains and Trusts then change the user’s Account tab to use the new UPN:

If adding a new UPN suffix is not acceptable, the user can configure their mailbox by select User another account and change the login username to domain\username:

Doing so will allow the user to successfully configure their mailbox:

I find this simple issue can throw a lot of administrators off so I hope this post would help save someone’s time.

Tuesday, October 15, 2013

You’ve set up federation between 2 Lync Server 2013 environments but notice that only 1 of the company can see presence information and have the ability to send messages while the other company is unable to see presence information from the other company, unable to send messages but is able to receive messages. Opening up a logging session on the Lync Edge server at the company that is unable to send or see presence information and the logs reveal the following error entries:

**Note that the user tluk@ccs.bm is able to send messages and view presence.

There wasn’t a whole lot I could find through searching the error messages so through logically thinking about it, what appeared to be the problem was that the company that could not send messages or see presence information was sending information out but wasn’t receiving any information back (hence the Thepeer did not respond to the connection attempt messages). Seeing how the other company that was able to send and see presence information was federated with other partners and was working properly, I figured it was probably because the other company probably had an outbound port blocked. A quick telnet via port 443 from the Edge server of the company that wasn’t able to send messages or receive presence information revealed that this was indeed the case and 443 was blocked. Once the Edge server was allowed TCP 443 outbound, the problem went away.