Export (0) Print
Expand All

Troubleshooting hybrid environments

SharePoint 2013
 

Applies to: SharePoint Server 2013

Topic Last Modified: 2014-04-17

Summary: Learn about common testing practices and how to troubleshoot common hybrid scenarios in SharePoint 2013.

This section provides general guidance on testing and troubleshooting hybrid environments.

Because a hybrid environment involves a complex security and authentication topology, it is important to test a given scenario to make sure that users can authenticate from expected locations and that permissions and security trimming produce the expected results. In many cases, the administrator accounts that you use to configure different components in the hybrid environment are not federated with your Office 365 tenant or may not have specific permissions to resources in SharePoint Server or SharePoint Online.

For example, in a two-way hybrid Search environment, an Office 365 Global administrator account cannot be used to test search queries from a SharePoint Online Search portal that is expected to return results from the on-premises SharePoint Server farm. These queries are unauthorized because native Office 365 user accounts cannot be authenticated by on-premises Active Directory and have no user profile object in the on-premises SharePoint Server farm. Similarly, an on-premises domain administrator account is unlikely to be federated. Therefore, it cannot be assigned permissions in a SharePoint Online site collection configured for hybrid Search. This account can't successfully use the SharePoint Server Enterprise Search portal to query SharePoint Online.

For these reasons, you should carefully design a test strategy that uses test user accounts that are configured specifically to emulate the authentication and authorization characteristics of a general user in your corporate environment.

The best practice is to design a test plan that follows these general principles:

  • Clearly define and document the scope, goal, and procedures for each test. Depending on your architecture and solution, these may include user authentication, authorization, latency between the user interface and data sources, user experience when authenticating from different networks and geographic locations, and component failover or high availability. Don’t cut corners by using cryptic notes or combining tests to save time.

  • Use test-specific user accounts configured to use group memberships and permissions that are designed to test specific functionality. Don’t reuse test accounts between tests because any changes that you make to accounts or permissions between tests may result in conflicts or artifacts that might obscure the test results.

  • For each test, decide at the beginning what makes up success or failure, and establish the specific determining factors.

It is important to test SSO using a non-administrator federated account to make sure that domain users can successfully authenticate. In some scenarios, you may have to test authentication for federated test users from both on-premises computers and the Internet to make sure that the federation identity provider is configured correctly. We recommend that when you design your test strategy, you plan for test client computers that are appropriately connected to either the on-premises network or the Internet/extranet and, to make sure that they are configured, use the security settings and software that you use in production.

Due to the complex nature of the technologies and trusts involved in a hybrid deployment, troubleshooting can require a wide variety of tools and skills. This section provides guidance on some of the tools and resources that can be useful for troubleshooting problems and configuration issues.

A key factor in troubleshooting is making sure that diagnostic logging is enabled in SharePoint Server and is configured to log verbose events to the event log and the trace logs. Also, you should configure verbose logging on reverse proxy devices, load balancers, and other network devices and data sources in your hybrid architecture. When your testing is complete, you should save your logs for future reference and reconfigure logging to an appropriate level for a production environment.

For more information about how to configure diagnostic logging in SharePoint Server, see Configure diagnostic logging in SharePoint 2013.

During testing, you should configure verbose diagnostic logging for the following categories on your SharePoint Server farm:

  • Secure Store Service: Select this top-level category and all subcategories.

  • SharePoint Foundation: Select this top-level category and all subcategories.

  • Services Infrastructure: Select this top-level category and all subcategories.

  • SharePoint Portal Server: Select the following subcategories:

    • Claims Authentication

    • User Profiles

    • Soap Server Exception

  • SharePoint Server: Select the following subcategories:

    • Distributed Cache

    • Logging Correlation Data

    • Shared Services

  • SharePoint Server Search: If you are configuring a hybrid search solution, select this top-level category and all subcategories.

  • Business Connectivity Services: If you are configuring a hybrid Business Connectivity Services solution, select this top-level category and all subcategories.

  • Duet Enterprise: If you are configuring a hybrid Duet Enterprise solution, select this top-level category and all subcategories.

The following table provides a list of troubleshooting tools that are frequently used to troubleshoot issues in a hybrid environment.

 

Resource Scope Link Notes

OnRamp

On-premises environment readiness for hybrid integration

OnRamp for Office 365

OnRamp for Office 365 is an automated assistance tool that helps you collect configuration requirements and perform deployment readiness checks against your on-premises environment.

Microsoft Online Services Diagnostics and Logging (MOSDAL) Support Toolkit

On-premises connectivity with Office 365, SSO

MOSDAL (Microsoft Online Services Diagnostics and Logging) Support Toolkit

The Microsoft Online Services Diagnostics and Logging (MOSDAL) Support Toolkit performs network diagnostics and collects system configuration, network configuration, and logging information for applications that are used to connect to Office 365. It includes the Active Directory Federation Services (AD FS) 2.0 Authentication Diagnostic tool.

Remote Connectivity Analyzer

SSO

Remote Connectivity Analyzer

Remote Connectivity Analyzer is a free connectivity test platform for Office 365. It tests the availability of the required Office 365 SSO service endpoint for expected behavior by acting upon those services from the Internet.

SharePoint Server ULS logs

SharePoint Server

View diagnostic logs in SharePoint 2013

ULS logs are the single most important source of SharePoint Server troubleshooting information.

ULS Viewer

SharePoint Server

ULS Viewer

ULS Viewer allows users to open SharePoint Server ULS log files and display their contents in a user-friendly format, with advanced functions such as filtering, sorting, highlighting, and reading real-time logging data.

This tool is necessary for reading ULS logs.

Log Parser 2.2

SharePoint Server and other on-premises logs

Log Parser 2.2

Log Parser is a powerful, versatile tool that provides universal query access to text-based data such as log files, XML files, CSV files, and key data sources on the Windows operating system such as the Event Log, the Registry, the file system, and Active Directory.

For more information about how to use Log Parser, see Log Parser Examples.

Windows PowerShell for SharePoint Online

SharePoint Online

Windows PowerShell for SharePoint Online

You can use the SharePoint Online Management Shell to efficiently manage users, sites, and organizations.

Some included cmdlets are useful for returning information to troubleshoot.

Fiddler

Web traffic debugging

Fiddler

Fiddler is a web debugging proxy that logs all HTTP and HTTPS traffic between your computer and the Internet. Fiddler allows you to inspect traffic, set breakpoints, and "fiddle" with incoming or outgoing data.

Microsoft Network Monitor 3.4

Network protocol analysis

Microsoft Network Monitor 3.4

Network Monitor 3.4 is a protocol analyzer. It allows you to capture network traffic and view and analyze it and is extensible with a range of experts and parsers for the analysis of specific kinds of traffic.

The following table provides links to web resources that may contain useful troubleshooting information.

 

Web resource Link Notes

How to update or to repair the configuration of the Office 365 federated domain

http://support.microsoft.com/kb/2647048

Several scenarios require rebuilding the configuration of the Office 365 federated domain in AD FS 2.0 to correct technical problems. This article contains step-by-step guidance on how to update or repair the configuration of the Office 365 federated domain.

Tips and FAQs: OAuth and remote apps for SharePoint

http://msdn.microsoft.com/en-us/library/fp179932.aspx

Get tips and answers to some FAQs for an app for SharePoint that runs in a remote web application and communicates back to SharePoint Server 2013.

Claims authentication does not validate user

Claims authentication does not validate user (SharePoint 2013)

This article describes the tools and techniques that you can use to troubleshoot failed claims-based user authentication attempts in SharePoint Server 2013.

Troubleshooting SharePoint 2013

Troubleshooting SharePoint 2013

Find quick access to information about how to resolve issues with deployments of SharePoint Server 2013.

Configure diagnostic logging in SharePoint 2013

Configure diagnostic logging in SharePoint 2013

Learn to configure diagnostic logging in SharePoint Server 2013 from the SharePoint Central Administration website or by using Windows PowerShell.

This section describes some common problems, such as error messages or connection failures, that you may encounter when you are testing a hybrid environment. It also contains potential solutions and specific clues that may help you to resolve the problem.

In this section:

You may experience any one of the following:

  • I searched from the SharePoint Online (SPO) search portal and see a non-specific error message, such as ”Sorry, something went wrong” or ”The request was aborted: The request was canceled.”

  • I have a Kerberos client error when I try to log on or run the Connect-MSOLService cmdlet with my global administrator account.

  • When I try to authenticate, I have three logon prompts, and after I enter my credentials three times, I get HTTP error 401.

Often, the cause of this type of error is a duplicate SPN (Service Principal Name) in Microsoft Online Directory Service (MSODS).

During the configuration of a SharePoint hybrid environment, you use the Windows PowerShell cmdlet Set-MsolServicePrincipal to register an SPN, which identifies your SharePoint on-premises farm to SharePoint Online. A duplicate SPN causes connection attempts to fail and may result in a variety of errors. Frequently, the errors say something about authentication, token signing, or Kerberos.

Example 1: Kerberos errors

The Kerberos client received a KRB_AP_ERR_MODIFIED error from the server <OnPremADFSName>$. The target name used was http://<yourOnPremADFSserver>.<yourdomainname>.com. This indicates that the target server didn't decrypt the ticket provided by the client. This can occur when the target SPN is registered on an account other than the account the target service is using. Make sure that the target SPN is registered on, and only registered on, the account that is used by the server. This error can also occur when the target service is using a different password for the target service account than what the Kerberos Key Distribution Center (KDC) has for the target service account. Make sure the service on the server and the KDC are both updated to use the current password.

Example 2: HTTP Error 401

NoteNote:
These steps are to be performed on the on-premises server only.

Server-to-server authentication in a hybrid environment (also known as identity management) depends on a Secure Token Service certificate that is shared by both the SharePoint on-premises server and the Office 365 tenant. Service Principal Names are used to register the on-premises domain (this is a wildcard registration) in the cloud. If there is something wrong with that SPN, you may experience three prompts ending in HTTP Error 401. If the certificate is at issue, sites may not be browsable with HTTP error 500.

If you are using ADFS for single sign-on (SSO), it is central to the process of authentication. If you have HTTP 401 errors, check for the following:

  • In the ADFS management console, make sure that the ADFS service is turned on, as shown in the following diagram.

    This diagram shows the status level of the ADFS 2.0 Service

    This is especially important if the error code that you receive is 408 (a time-out). For a list of error codes, see The HTTP status code in IIS 7.0, IIS 7.5, and IIS 8.0.

  • Increase the logging level for ADFS. The following diagram shows what logging levels should be turned on for ADFS.

    This diagram shows what logging levels should be turned on for ADFS

    For additional information about how to set up auditing or logging for ADFS, see Configuring Computers for Troubleshooting AD FS 2.0.

  • Repeat the action that caused HTTP Error 401 or 408 again and capture the log file. This method helps to increase your chances of resolving the issue by giving more of a description for a given error. For example, the service account running ADFS 2.0 has to be granted Generate security audit permission on the ADFS 2.0 servers. If it is not, an error (Event ID 209 - The security log event source for the Federation Service couldn't be registered) will be logged.

  • After you attempt to log on three consecutive times and HTTP Error 401 is still displayed, you may want to check your SPNs first. Go to the SharePoint front-end web server where you configured the hybrid trust. This should have all the modules loaded that you need.

Resolve duplicate SPNs in Office 365
  1. You use Windows PowerShell to connect to, query, and configure Office 365.

  2. Go to Start > All Programs > Windows PowerShell.

  3. From the Windows PowerShell command prompt, type the following commands.

    Add-PSSnapin Microsoft.SharePoint.PowerShell
    
    Import-Module Microsoft.PowerShell.Utility
    
    Import-Module MSOnline -force
    
    Import-Module MSOnlineExtended -force
    
    Import-Module Microsoft.Online.SharePoint.PowerShell -force
    
  4. Provide the credentials for the Global Administrator account by typing the following commands.

    $cred=Get-Credential
    
    Connect-MsolService -Credential $cred
    
  5. Display the SPNs registered for your Office 365 tenant by typing the following commands.

    $app=Get-MSOLServicePrincipal-AppPrincipalID 00000003-0000-0ff1-ce00-000000000000
    
    $app.ServicePrincipalNames
    

    From the result list, you mainly look for duplicate SPNs. Commonly, these take the form of an explicit SPO principal when you've also registered a wildcard principal. Explicit principals are not needed. For example, you may see both '00000003-0000-0ff1-ce00-000000000000/sharepoint.adventureworks8.com' and '00000003-0000-0ff1-ce00-000000000000/*.adventureworks8.com'.

  6. Only the wildcard SPN is needed. Use the Remove-MsolServicePrincipal cmdlet to remove the explicitly named SPN. In Business Connectivity Services, the error message may be displayed as The internet facing URL for the LobSystem (External System) returned an authentication error.

    When you perform a hybrid operation using Business Connectivity Services or Duet, collecting SPN information should be part of standard troubleshooting when connection and authentication error messages occur. You should keep a record of the working SPN configuration for comparison and as a backup.

Verify your settings by following these steps in the on-premises environment:

  • On the on-premises based computer, verify your web browser proxy settings.

  • If you're using a network load balancer, either go directly to a web server, bypassing the NLB, or take a front-end web server out of rotation on the NLB and do your testing on that web server.

  • If you have network trace tools that act as a proxy installed on your web server, uninstall them.

  • Check alternate access mapping settings in the SharePoint Central Administration website by going to System Settings > Configure alternate access mappings:

    • Browse to the URL of the default AAM zone and any URL you use for intranet browsing. Record any errors and check ULS for that date and time.

    • If your hybrid authentication topology is inbound or two-way, you can go to the public URL from a computer that has the Secure Channel certificate installed to validate the inbound connection. Enable logging on your reverse proxy device, and then navigate to the external URL (the same URL you used to configure the Secure Store Target App in SharePoint Online). The reverse proxy logs and the on-premises SharePoint Server ULS logs will show information about whether the request was relayed by the reverse proxy and whether it was processed by SharePoint Server.

      ImportantImportant:
      You should install the Secure Channel certificate on a computer only for test purposes.
  • Run the Nslookup tool to make sure that you can resolve the Domain Name System (DNS) names of the SharePoint Server URLs. For additional information about the Nslookup tool, see Using Nslookup.exe.

  • Review the Unified Logging Service (ULS) logs and network traces for errors.

Verify your settings by following these steps in the on-premises environment:

  • If you're using an incoming or a two-way configuration, you should have made a new STS certificate that is used by both on-premises and Office 365. This certificate is for signing tokens and authenticating users.

  • Make sure your database is up and running correctly.

  • Review errors in the Windows event logs on the SharePoint Server front-end web server hosting the primary web application.

  • Review errors in the ULS logs for the on-premises SharePoint Server farm.

  • Check the expiration date of the SharePoint STS certificate. If errors indicate that token signing is broken or otherwise indicate a certificate issue, you may have to replace your STS certificate. For information about how to replace the STS certificate, see Replace the STS certificate for the on-premises environment.

  • If you have a trial version of Office 365, verify that the subscription is not expired. If you don't know when the trial version expires, go to your Office 365 Administration Center > Licensing > Subscriptions, and look at the term end date of your Office 365 SKU.

While in an on-premises environment, you may receive any one of the following error messages or problems:

  • The error message "Bad request exception" may be logged in a ULS log file.

  • An Open Authorization (OAuth) error message occurs during the logon process.

  • You receive the exception error message ValidTo date must be set to on or before the date that the X509 certificate is valid until.

All of these error messages may point to the SSL certificate. These error messages occur during server-to-server authentication. This often means there was a typo or mistake when you configured the STS certificate. A common error is entering an incorrect end date for the certificate.

For example, when a new STS certificate is created for use in an on-premises environment and then uploaded to Office 365, make sure that you type the values for <start_date> and <end_date> in the format 00/00/0000 (month/day/year).

The <start_date> value should be the current date, and the <end_date> value should be the STS certificate expiration date, unless you are using a trial version of Office 365.

If you’re using a trial version of Office 365, the <end_date> must be a date before the trial subscription's expiration date, or the Windows PowerShell command will fail. For example, if today's date is March 21, 2013, and your Office 365 trial subscription expires on April 19, 2013, you could use the following code.

New-MsolServicePrincipalCredential -AppPrincipalId $spoappid -Type asymmetric -Usage Verify -Value $credValue -StartDate 3/21/2013 -EndDate 4/18/2013
NoteNote:
Either specify correct dates or rerun this command using no dates. When no dates are used, this causes the Windows PowerShell command to revert to the dates in the certificate itself.

The following text is a general guideline that can be used to get Search working:

  • Before testing Hybrid search, choose a specific federated test account and ensure the account is added to a SharePoint Online website. You must be able to log on with this user, navigate the SPO site, and open the SPO content that you'll later search for. If you can do this, you can test Hybrid Search with this account. Likewise, if Hybrid Business Connectivity Services is used, make sure that the federated user that you test with can open the app or browse the list that is used with Business Connectivity Services.

There are several possibilities for this issue to occur. You can check the following items:

  • Are you logged in as a federated user?

    If you're testing a Hybrid solution, test everything as a federated user.

  • The user may have other accounts in the cloud, but when you log on to test, log on with the domain name that matches the federated domain's UPN. For example, if I federated adventureworks8.com, log on as abarr@adventureworks8.com so that ADFS can discover and correctly route your access request.

  • Make sure your user accounts have the user principal name (UPN) that you used during identity federation by following these steps:

  1. Go to your on-premises domain controller (DC).

  2. On your on-premises domain controller (DC), open Active Directory Users and Computers.

  3. Find the user account you want to use.

  4. Make sure the UPN matches the UPN used for federation.

  • Check the UPN for the user’s federated account in the Office 365 Administration Center:

    1. From Users and Groups in the Quick Launch, click the magnifier icon.

      This diagram shows the magnifier icon located from the Quick Launch bar
    2. Type the alias, and then press Enter. Make sure you log on with the federated UPN. If your account doesn't display the correct UPN, change the UPN in your on-premises Active Directory. When you locate the account, there will be a drop-down where you can select the correct UPN and Dirsync, as shown in the following diagram.

      This diagram shows how to obtain the UPN from the Office 365 Administration Center
  • Does search work in SharePoint Online for SharePoint Online documents?

    To check, go to your Enterprise Search page and test with some general queries. Are SharePoint Online results displayed when in SharePoint Online, or do you receive an error message? Likewise, make sure that you can search in SharePoint on-premises.

  • Use the query builder to test search both on-premises and online.

    The following steps are to be performed in a SharePoint Online environment:

    1. Log on as the Global Administrator or SharePoint Online Tenant administrator. Go to Admin > SharePoint, as shown in the following diagram.

      This diagram shows the account logged in from the Office 365 Admin Center

      NoteNote:
      If you configured the search result source for a specific tenant inside of that website, go to https://<tenant name>.sharepoint.com, and make sure to sign in with at least a site collection administrator.
    2. From the Quick Launch navigation pane, click Search, as shown in the following diagram.

      This diagram shows how to get Search from the SharePoint Admin Center
    3. Click Manage Results Sources, and choose the result source you defined for SharePoint on-premises.

    4. Scroll down, and click the Launch Query Builder.

    5. Type in a word for your query that exists in the on-premises and SharePoint Online environments, and then click Test Query.

    6. Make sure you get results from the on-premises environment, and if there are no results, copy and paste the entire error that appears in the Search Result Preview pane to your notes.

    Check the Search settings for the on-premises environment
    1. Browse to your SharePoint site. Go to Site settings > Search Result Sources.

    2. Click the result query you defined for SharePoint Online > Launch Query Builder. You should be on the Basics tab. The following diagram shows a result source.

      This diagram shows the result source defined for the SharePoint Online site collection

    3. Input a query after {searchTerms}. You can also use a wildcard (asterisk/*).

    4. Make sure you get results from SharePoint Online. If you get an error message, copy and paste the full message in the Search Result Preview pane for your notes.

  • Review the ULS logs on the on-premises computer. Look for {searchTerms}. In the following diagram, the ULS Viewer tool is used. Right-click the correlation ID to limit the results to messages related to that search.

    This diagram shows how to obtain get results from the Correlation ID by using the ULS Viewer tool

  • If the results don’t contain enough detail, before you make another query, go to Central Administration > Monitoring > Configure Diagnostic logging, and then set the Least critical event to report to the event log and to the trace log dropdown boxes to Verbose.

    Click the following check boxes to enable them:

  • SharePoint Portal Server

    • Claims Authentication

    • Soap Server Exception

    • User Profiles

  • Authentication Authorization

  • Claims Authentication

  • Secure Store Service

  • Services Infrastructure

  • SharePoint Server

    • Logging Correlation Data

    • Shared Services

These steps are to be performed in the SharePoint Online environment:

  • You can't view ULS logs for SharePoint Online, but you can submit a request for help to check existing logs by doing the following steps:

    1. From the Administration dashboard, click Get help and online support, and then click new service request, as shown in the following diagram.

      This diagram shows how to contact online support by using the new service request button

    2. Type your problem by being detailed and concise, as shown in the following diagram.

      This diagram shows the different detailed descriptions to add when a service request is sent to technical support

      If applicable, attach the on-premises ULS logs and other supporting files to the message. Notice that you can call support directly from these pages, as shown in the following diagrams.

      This diagram shows the new service request settings and how to contact support

      This diagram shows how to attach a file to submit to technical support

      When you call, it's best to be ready with logs and the full error message and to be prepared to reproduce the issue for the person helping you.

  • If the SharePoint Online and SharePoint on-premises search environments are working correctly, you should check devices in between and prepare to read a network traffic trace:

    • If you are in an incoming or two-way hybrid search configuration, you need to go to your reverse proxy and check the logging there for any error messages.

    • Errors from a network trace may confirm that you are receiving a request from SharePoint Online, for example, but not sending it to on-premises. At this point, review recent changes or updates to the reverse proxy.

    • Review the rules that allow the traffic to pass through your reverse proxy, making sure that the configuration complies with the guidance for your reverse proxy device, and record the error messages in a worksheet.

    • If the reverse proxy still rejects inbound traffic from Office 365, you may need to contact your reverse proxy vendor for help.

NoteNote:
Be careful with network trace tools that act as a proxy. They may need to be removed after you test to avoid interference with normal proxy function. However, some of these network tools allow you to decrypt SSL traffic by loading your certificate.
  • If you are in an outgoing configuration, you do not pass through a reverse proxy. You may pass through a forward proxy. At this point, you may want to try any of the following items:

    • Install a network tracing tool on an on-premises web server.

    • Install the network tracing tool on the forward proxy.

    • Allow both network tools to capture and do not filter the network traces.

  • Re-create a query from an on-premises environment that goes to a SharePoint Online environment. Use a memorable term.

  • When the search results are returned, stop both tools and save both traces with meaningful names—for example, 'RPTrace<date><time>BROKENSearch' and 'WebSvr3Trace<date><time>BROKENSearch'.

  • Filter the traffic after the fact. You can filter the results by using the search term that you used.

  • You can combine the network traffic traces with ULS logs with the same date and time for a richer picture of the issue.

Directory Synchronization is sensitive to blocked ports. If a new user account does not synchronize after the wizard is run again (there may be as much as 2-3 hours between synchronizations), you may want to check that the ports for Lightweight Directory Access Protocol (LDAP), Kerberos, SQL, and remote procedure call (RPC) are open on any firewalls between your Directory Synchronization server and the Internet. Other ports to unblock when you test include Simple Mail Transfer Protocol (SMTP) (that is, port 25) and Secure Sockets Layer (SSL) (that is, port 443). If Directory Synchronization is configured to use Password Sync, the passwords should synchronize more quickly than the remaining metadata around a user. To test this, change the password of an existing test account and check to see if you can log on to Office 365 with the account’s new password at the five-minute or ten-minute mark.

Other things to consider are:

  • If directory synchronization fails, you should also consider restarting the Directory Synchronization server and consider taking network traces of the synchronization.

  • Monitor the on-premises ULS log files for progress reports and error messages.

  • It is important to monitor or collect Application Event Viewer logs (click Start > Run, and then type eventvwr) on the Directory Synchronization server throughout the day.

    • If you want to check whether Directory Synchronization is working correctly, go to C:\Program Files\Microsoft Online Directory Sync\SYNCBUS\Synchronization Service\UIShell\miisclient.exe and check the accounts getting synchronized.

      NoteNote:
      You can't edit the Directory Synchronization configuration with the MIISClient.exe tool because this modification is not supported and can make the synchronization unstable.
    • Go to the Office 365 Administration Center and refresh the Users and Groups page. This will update with synchronized accounts marked “Synced with Active Directory”.

      NoteNote:
      You can also activate any synchronized users in this list. This allows you to assign a license to users that gives them the rights to use SharePoint Online.
    • Directory Synchronization errors and general information are recorded in this log. If you're having a Directory Synchronization issue, become familiar with logging in Event Viewer, which can capture everything from errors connecting to MSODS (for example, because of permissions) to DNS or Domain Controller (DC) access errors.

      Look for any of the following messages:

    • Attempting to start synchronization now

    • Running full import

    • Confirming Import has completed

    • The cumulative number of objects processed by the current 'export' run: <some number>

    • Any timeouts or errors in this process

Was this page helpful?
(1500 characters remaining)
Thank you for your feedback
Show:
© 2014 Microsoft