Showing posts with label exchange. Show all posts
Showing posts with label exchange. Show all posts

Tuesday, 8 October 2013

Lync 2013 client popup credentials are required for Outlook

When we started migrating users to Exchange 2013 and Lync 2013, users began complaining of being prompted to enter their credentials for Outlook when starting Lync.

The exact error message is:
Credentials are required
Lync needs your username and password to connect for retrieving calendar data from Outlook


We did some Wiresharking and found this to occur when Lync was connecting to the EWS and Autodiscover Exchange URLs.



The Solution

1. Ensure your internal and external EWS/Autodiscover URLs are in the Internet Explorer local intranet zone. This will be extremely helpful in assisting you to troubleshoot the problem.

2. Logon to your Exchange server and open IIS.

3. Click the EWS directory under "Default Web Site".

4. Open Authentication, click Windows Authentication and then Providers.

5. Remove all entries except for NTLM.



6. Repeat the same for the Autodiscover directory.

7. Restart IIS.

Now restart your client and you should no longer be prompted for Outlook credentials.



Additional troubleshooting tips

Internet Explorer debug tools are great for troubleshooting authentication issues, but first ensure your EWS/Autodiscover URLs are in the Internet Explorer local intranet zone.

A simple test is to go to the EWS URL (http://yourdomain/EWS/exchange.asmx) in Internet Explorer, it should automatically negotiate authentication and show you the service page. If you don't receive the "You have created a service" page then your single sign on is not correctly configured.

1. Open Internet Explorer and press F12 to launch the debug tools.

2. Click Network and "Start Capturing".

3. Now open your EWS URL: http://yourdomain/EWS/exchange.asmx

4. Click "Stop Capturing" and click "Go to detailed view"

You can see the order of the authentication providers and any issues that might have occured during authentication. You can then repeat the same for Autodiscover, remember if Autodiscover can't negotiate pass through authentication then it will prompt the Lync user for credentials.



Wednesday, 2 October 2013

Integrating Office Web Apps 2013 with Exchange 2013 OWA and UAG gateway

Office web apps 2013 (OWA) is a great way to extend the functionality of Exchange 2013 Outlook Web App and give full Powerpoint viewing functionality in browser. When we built our new Exchange 2013 environment we wanted to offer Office Web apps internally and externally.

After building our environment we had no problems making OWA work internally with Outlook Web App, but externally we always received error messages from OWA.

"Sorry, we couldn't open this presentation because we ran into a problem. Please try again."



Our external Outlook Web App is accessed via a Forefront UAG trunk, however there were no error messages on the OWA, Exchange or UAG servers indicating a problem.

We ran Wireshark packet trace on the OWA server and found that when the request for the Powerpoint web app was established externally, the OWA server tried to establish a connection to UAG. This makes sense as the Powerpoint file needs to be transferred from Outlook Web App to OWA somehow and UAG stands in its way.



The Resolution

1. Create a simple A record in the hosts file of the OWA server.The A record should be the FQDN of your UAG trunk to the internal IP address of your Outlook Web App server, a load balancer address is fine here.

In our circumstance we needed to re-issue the Exchange certificates to include the UAG FQDN in the subject alternate name of the certificate. We tried without re-issuing the certificate but received the same "Please try again." error messages as above. As you would expect the OWA server is rejecting the certificate as it doesn't contain the correct FQDN.

You also need to ensure your OWA server has network connectivity to the HTTPS port of your Outlook Web App server.

While this is a simple fix, it did take us a while to even consider trying this. Now we have lots of happy users able to preview power point and word documents externally.

Tuesday, 1 October 2013

Outlook & Lync 2013 prompting for authentication with Exchange 2013 Outlook Anywhere

We are currently undergoing a massive migration from Exchange, Lync and Sharepoint 2010 to 2013. The first service being migrated is Exchange, making way for Lync and later Sharepoint. During our Exchange migration it hasn't all been smooth sailing, before we even got started we had to wipe our DAG and start again. However with a little persistence we got a trial DAG up and running and migrated a couple test mailboxes.

As we got into the trial we found some users with Outlook 2013 had single sign on (NTLM) while others were prompted for authentication. This also effected Lync as the UCMAPI service connects to Exchange via Outlook, so Lync was also prompting for credentials when the user logged in. While a password prompt is acceptable for external use, we were not happy with this for internal devices.

Clients that were prompted for authentication were able to single sign on to rpcproxy and EWS with Internet Explorer, so the problem didn't seem server based.

Hours were invested trying to resolve this problem, so of the fixes we attempted were:

  • Packet tracing
  • IIS log tracing
  • Re-creating RPC and EWS directories
  • Changing authentication in the Outlook client
  • Changing authentication on exchange virtual directories
  • Changing IIS authentication
  • Adding exchange domains to local intranet zone in Internet Explorer
  • Bypassing load balancers
  • Client based registry hacks
  • Client application re-installation


The Resolution

We were nearly at the point of building a second Exchange environment for testing when we made a breakthrough, I almost feel embarrassed admitting the problem, group policy.

Our legacy Exchange 2010 group policy was set up for RPC internally and https Outlook Anywhere externally, however we never set the MSSTD field, in fact we implicitly removed it with GPO.

As soon as we set the MSSTD field to one of the SAN names of the certificate (wildcards certificates are also fine), the Outlook client single sign on worked perfected and Lync stopped asking for authentication on sign in.

Hopefully you don't waste as much time as we did on this problem.

Friday, 6 September 2013

Exchange 2013 mail stuck in draft - Mailbox Transport Submission service failing to start

We just recently begun building an Exchange 2013 DAG to support out email environment. This is part of an internal shift to Lync 2013 and Exchange 2013 for unified communications. We followed Microsoft instructions on building my first 2013 machine, migrated a single test mailbox and started testing.

We found no mail flow between the Exchange 2013 and Exchange 2010 environments, all email sent from 2013 OWA or Outlook was just sitting in the drafts folder. In fact even if I emailed within mailboxes on the 2013 mail database they would also stay in drafts.

Upon investigating this problem there was a failure of the "Microsoft Exchange Mailbox Transport Submission", "Microsoft Exchange Transport" and "Microsoft Exchange Frontend Transport" services.



The Problem

Windows application event logs showed the following errors when trying to restart the "Microsoft Exchange Mailbox Transport Submission" service.
Log Name: Application
Source: Application Error
Event ID: 1000 
Faulting application name: MSExchangeSubmission.exe, version: 15.0.712.12, time stamp: 0x51aff4c9
Faulting module name: unknown, version: 0.0.0.0, time stamp: 0x00000000
Exception code: 0xc00000fd
Fault offset: 0x000007fb0b3cc301
Faulting process id: 0x2894
Faulting application start time: 0x01ceaa8fd8cefada
Faulting application path: C:\Program Files\Microsoft\Exchange Server\V15\Bin\MSExchangeSubmission.exe
Faulting module path: unknown
Report Id: 179beb57-1683-11e3-93f5-00155dd80a77
Faulting package full name:
Faulting package-relative application ID: 

There is also another event log with some more telling information.
Log Name: Application
Source: MSExchangeTransportSubmission
Event ID: 7010 
The activation of modules are taking longer than expected to complete. Current state of components:<LoadTimings>
....
  <Component Name="Dns" Elapsed="00:00:23.1781923" IsRunning="true" />
</LoadTimings>
<StartTimings />
<StopTimings />
<UnloadTimings />
It is indicating that the DNS component was failing to start in a timely manner.



The Resolution

We checked and double checked our DNS, no issues. We also followed a number of blogs that indicate you need disable IPv6 and manually select the network adapter under DNS lookups on the Exchange server properties. We did this to no avail, however the actual resolution wasn't far off.
1. Open Exchange 2013 ECP
2. Go to "Servers" tab
3. Select "servers" from across the top menu
4. Double click the problematic server from the list of Exchange servers
5. Select "DNS lookups"
6. Instead of selecting your network adapter, select "Custom settings" under "External DNS lookups"
7. Add all your DNS servers
8. Repeat the same for "Internal DNS lookups"
9. Restart the above failing transport services
10. Rejoice


This seems to be a bug with a .NET 4 module Microsoft.Exchange.Net.ni.dll. Selecting "Custom settings" bypasses this .NET bug.

If you are still having issues with mail flow, ensure your new Exchange 2013 server has a system mailbox and consider removing the Exchange 2013 server, wiping AD clean and starting a fresh install.

Friday, 11 May 2012

Exchange 2010 OWA users report a blank screen after first login

I recently provisioned a number of Exchange 2010 e-mail accounts as part of a mail roll-out project I was undertaking. The owners of these accounts prodominatly access their accounts via outlook web acces (OWA) using forms based authentication, both via a local instance and another instance sitting behind Forefront UAG.

Provisioning the accounts was the easy part.


The Problem

As soon as I started handing these accounts out, users were reporting the inability to get past the select language screen. Users were able to log in without issue, but after selecting an appropriate language and time-zone they simply recieved a blank screen. Anyone who was persistent enough to try 3 times in a row eventually did get in, and after they were in once, they didn't have any more problems.

After replicating the issue and confirming it was in fact happening, I checked eventvwr, exchange logs and IIS logs but I was unable to pinpoint what was causing the problem. In fact the logs had nothing unusual at all in them.

I was able to determine the blank screen was when the web browser was attempting to access the following URL: https://OWAURL/owa/lang.owa


The Fix

As the problem seemed to disappear after the user entered and accepted the time-zone and language data 3 times, I thought I would try forcing the local ID onto the OWA instances in question.

Voila, after executing the following command into an Exchange powershell console, users no reported any issues.

Set-OWAVirtualDirectory "owa (Default Web Site)" -DefaultClientLanguage <Locale ID>

You can use this table provided by Microsoft to search for your Locale ID.

If you are using a custom OWA instance with a different name, you can use the following command to get a list of all the OWA instances on your server.

Get-OwaVirtualDirectory

Hopefully you are smart enough to do this BEFORE you start adding accounts and not when users start having problems.

Friday, 7 October 2011

Lync 2010 reports lync cannot connect to the exchange server

While this hasn't been causing us any problems (yet), I am planning to use Lync 2010 with Exchange 2010/Outlook calendar integration shortly and until all Exchange connectivity issues are resolved, this can't be achieved.



The Problem

After the Lync 2010 client has been open for around a half hour or so, a red error box appears in bottom right hand corner of the client, clicking on the error displays a message.
Exchange Connection Error - Click to display details.

and then after clicking that error we see a further error message.
Lync cannot connect to the Exchange server. Lync will attempt to retry the connection.


Investigating the problem

To get some more information you can hold CTRL and right click on the Lync 2010 icon in the notifications area and select the "Configuration Information" window. This window shows how Lync is setup and potentially will display any problems.

On my configuration I noticed the "EWS Internal URL" and "EWS External URL" were both blank, and the "EWS Information" had a status of "EWS not deployed". I know it certainly is deployed, but just to be sure I verified it was configured and there was a instance of EWS under my Exchange 2010 IIS instance.


What I also noticed after browsing through my registry, was that the "Autodiscover" key was totally missing our of my Lync configuration. The following key should exist, replace <SIP> with your sip account name, so for me it was jtrevaskis@domain.edu.au

HKCU\Software\Microsoft\Communicator\<SIP>\Autodiscovery

If the Autodiscovery registry key does not exist, then your Lync client has not been able to connect to the Autodiscovery service of outlook and resultantly it cannot enumerate the locations of critical Exchange services such as EWS that will seed the Lync client information.



But I already have the Autodiscover service configured perfectly

Well that is what I thought too! What I didn't realize is that when I originally configured Lync I set my client domain as my external domain. It is important to identify what your SIP domain is, so when you log into Lync, what address is used, for me it was my external email domain and this is the root cause of my problems.

Internal Domain: domain.internal
External Domain: domain.edu.au

So while I have my DNS records for autodiscover.domain.internal A and _autodiscover._tcp.domain.internal SRV configured perfectly, the Lync client is actually looking for for autodiscover services at autodiscover.domain.edu.au and _autodiscover._tcp.domain.edu.au

I ran a quick Wireshark session to confirm my suspicions and within a few minutes of starting the Lync client I was seeing DNS lookup requests for _autodiscover._tcp.domain.edu.au



The Solution

I don't really want to offer Autodiscover services to the outside world and I don't want to publish _tcp records onto my external DNS services. After all, my Lync clients are being used internally only, so I wanted to find a solution that would work internally without disclosing too much information.

I got it! OK this is a little bit of a hack, but it works perfectly for me, and ensures none of my internal DNS records need to be published on the internet.

1. I created a _tcp.domain.edu.au zone on my internal DNS servers.

2. In my newly created zone, I added a SRV record by right clicking the zone and selecting "Other Records" and then "SRV".

3. I entered _autodiscover as the service type, _tcp as protocol, 443 as port number and the FQDN of my Exchange IIS service instance that is offering my Autodiscover and EWS services.

That is it, simple as that! I restarted my Lync client and within 5 minutes the "Configuration Information" window was displaying the correct EWS URL's and the HKCU\Software\Microsoft\Communicator\<SIP>\Autodiscovery registry key had been created and fully populated.

If you want to use Lync externally or already have external _tcp DNS records, then you can easily point your clients to an external EWS server and achieve the same result.

The main requirement is that a _autodiscover._tcp SRV record points directly to your Exchange IIS instance that is hosting EWS. As long as you achieve that, be it via a hack like mine, or publishing external _autodiscover._tcp records and pointing them to an external EWS instance, it should work.



Other issues worth investigating

If you are still having issues, it would be worth checking your Exchange 2010 IIS instance to ensure Autodiscover and EWS are configured and that you can reach the Autodiscover service via https://domain/Autodiscover/Autodiscover.xml to which you should see some XML random returned.

Also ensure that when you visit you Exchange IIS instance https://  in a web browser via the same FQDN you entered in your DNS SRV record above, you receive no certificate errors. If there are any certificate errors you will need to resolve them before Lync will be able to reach the Autodiscover service.

Monday, 1 August 2011

Creating shared calendars in exchange 2010 and assigning groups permissions

With the release of Exchange 2010 Microsoft once again made their intention of killing off the "public folder" features blatantly clear. So what does this mean for those wanting to create shared calendars? Well now there are a few hoops to jump through to achieve the goal.

The best solution seems to be to create a new mailbox, then assign permissions to that mailbox's calendar. Unfortunately you can't assign a distribution list access to a shared calendar and this is the step where those new to Exchange 2010 stumble, the answer is Universal Security groups.

Alternatively you can pipe all the distribution list members into a PowerShell script then assign then permissions to the shared calendar.

Get-distributiongroupmember –id Groupname | Add-MailboxFolderPermission -Identity “UserMailbox”  -AccessRights Owner

You would need to repeat this process when you add new users to the distribution list, not a desirable configuration.


Before we get started...

To create our new shared mailbox/calendar is made easier by using a script by Steve Goodman called New-SharedCalendar.ps1, you can grab it from Steve's blog. http://www.stevieg.org/tag/shared-mailbox/



Creating a shared Calendar in Exchange 2010

1. Create a new Universal Security group in active directory, in my case I called the group STAFFUV and then you nest the existing global or domain local security groups within this universal group. You can always just create universal groups and assign users directly to them (or use existing universal groups) but this could mean more administration on your behalf not to mention being against best pratice.

If you want to give different user groups different permissions in the calendar it might be best to create a number of universal groups, e.g. STAFFUV_reviewers STAFFUV_owners and then nest the appropriate groups within them.


2. Next we fire up an Exchange PowerShell console and create our spanking new mailbox using steve's New-SharedCalendar.sp1. This script has the ability to assign users with owner, editor or reviewer permissions.

Lets just assign an "owner" at this stage, then assign the universal groups that we want to use in step 3.

New-SharedCalendar.ps1 -Name "Test Calendar" -Owners "username"


3. We have successfully created our "Test Calendar" mailbox. Steve's script is kind enough to set that mailbox not to be automatically mapped, this is extremely important or Outlook 2007 and above will automatically map that shared mailbox when the user opens their Outlook client.

Next we need to assign permissions using our previously created universal security groups.

Add-MailboxFolderPermission -Identity "Test Calendar:Calendar" -User "STAFFUV" -AccessRights "Reviewer"

You may need to repeat the above command a number of times depending on how many universal groups you want to assign permissions to. The beauty of this process is now when add a user to STAFFUV or one of its nested groups they automatically get the access rights assigned to the universal group, no manual adding.

Breaking down the above command, firstly we have the -Identity variable where we are specifically targeting the "Test Calendar" user's calendar with the ":Calendar" syntax. Secondly we are specifying our previously created universal group "STAFFUV" as the user, and lastly we are giving the STAFFUV group the permission of "Reviewer" which is a read only permission.



Alternatively you can assign:
Owner                                                CreateItems, ReadItems, CreateSubfolders, FolderOwner, FolderContact, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
PublishingEditor                       CreateItems, ReadItems, CreateSubfolders, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
Editor                                                 CreateItems, ReadItems, FolderVisible, EditOwnedItems, EditAllItems, DeleteOwnedItems, DeleteAllItems
PublishingAuthor                    CreateItems, ReadItems, CreateSubfolders, FolderVisible, EditOwnedItems, DeleteOwnedItems
Author                                              CreateItems, ReadItems, FolderVisible, EditOwnedItems, DeleteOwnedItems
NonEditingAuthor                   CreateItems, ReadItems, FolderVisible
Reviewer                                          ReadItems, FolderVisible
Contributor                                   CreateItems, FolderVisible


4. You have now completed the process, give these changes some time to propagate and when you see the "Test Calendar" user appear in your global address book you can map the "Test Calendar" and proceed with your newly created shared calendar.


This certainly isn't as easy as the old point and click GUI in Exchange 2003 but the PowerShell applets give much more flexibility with automating Exchange functions during the adduser process.