KB Articles

Page 1 of 72712345...102030...Last »

A description of the support of the localized Outlook client in Exchange 2000 Server

This article describes the support of the localized Microsoft Outlook client in Microsoft Exchange 2000 Server.

Warning Serious problems might occur if you modify the registry incorrectly by using Registry Editor or by using another method. These problems might require that you reinstall the operating system. Microsoft cannot guarantee that these problems can be solved. Modify the registry at your own risk.
In Microsoft Exchange Server 5.5, you had to add a code page to Microsoft Windows NT Server and locales to Exchange Server to enable the support of multiple languages. In Exchange 2000, however, this situation has changed.

In a multiple language or localized environment, some user display names may be in English and others may be in localized languages, such as, German, French, or Chinese. When an Outlook client views the global address book, the display names may be not sorted correctly.

Exchange 2000 does not have an independent directory service, and Exchange 2000 is closely integrated with Microsoft Windows 2000 Active Directory. When a Microsoft Outlook 2000 client attempts to obtain the global address book, the client directly contacts the preferred global catalog. For an earlier-version Outlook client, Exchange 2000 server can obtain the global address book from global catalog and forward it to the client.

To have the global address book sorted correctly, you must configure Windows 2000 domain controller and global catalog to support the languages that are going to be used. To do so, you must perform the following steps on all global catalogs and domain controllers:

  1. In Control Panel, double-click Regional Options.
  2. On the General tab, under the Language settings for the system section, click to select the check box for the language that is going to be supported.
  3. Restart your computer for the changes to take affect.
  4. Start Registry Editor (Regedit.exe).
  5. Click to expand the following subkey in the registry:

    HKEY_LOCAL_MACHINE/Software/Microsoft/Ntds/Language

  6. Right-click Language, point to New, and then click DWORD Value. Enter a name for the string, and then press ENTER.
  7. Right-click the DWORD value that you just created, and then click Modify. In Value data, enter the value of the locale identification (ID) that you want to support.
  8. Restart the global catalogs and domain controllers.

For list of locale identification (LCID) numbers, visit the following Microsoft Web site:

http://office.microsoft.com/en-us/word-help/locale-identification-numbers-for-language-specific-files-HA010351417.aspx

(http://office.microsoft.com/en-us/word-help/locale-identification-numbers-for-language-specific-files-HA010351417.aspx)

Article ID: 301314 – Last Review: August 1, 2014 – Revision: 4.0


Applies to
  • Microsoft Exchange 2000 Server Standard Edition
kbnosurvey kbhowto kbarchive KB301314

Link:
A description of the support of the localized Outlook client in Exchange 2000 Server

How to change your user photo in Office 365 by using Outlook Web App

This article describes how to use Outlook Web App to change your user photo that’s displayed in Exchange Online in Office 365, Lync 2013, and Lync Web App. 
To use Outlook Web App to update your user photo in Exchange Online, Lync 2013, and Lync Web App, follow these steps: 
  1. Sign in to Outlook Web App.
  2. Click Settings (

    Collapse this imageExpand this image

    ), click Options, and then on the My account page, click Edit information.

  3. On the account information page, click photo, click change, and then click Browse.
  4. Browse to the picture that you want to use for your user photo, and then select it.
  5. Wait for the picture to upload. This may take some time, depending on the size of the picture and the network connection.
  6. Click save.
In Office 365, user photos are stored in the following locations:
  • A low-resolution photo (less than 100 KB) is stored in the user’s ThumbnailPhoto attribute in Active Directory. This is the photo that’s synchronized to Office 365 in a hybrid environment. Low-resolution photos are used by Lync 2010.
  • A high-resolution photo is stored in the root directory of the user’s Exchange Online mailbox.  High-resolution photos are displayed in Exchange Online, Lync 2013, and Lync Web App.

Still need help? Go to the Office 365 Community

(http://community.office365.com/)

website.

Article ID: 2986893 – Last Review: July 31, 2014 – Revision: 2.0


Applies to
  • Microsoft Exchange Online
  • Microsoft Lync Online
  • Microsoft Lync 2013
  • Microsoft Lync Web App
o365e o365p o365m o365022013 o365 o365a kbgraphic kbgraphxlink KB2986893

View article:
How to change your user photo in Office 365 by using Outlook Web App

WCF Service does not start automatically when messages are available through MSMQ

An IIS application pool is hosting two distinct WCF services where one uses the net.msmq binding and the other uses msmq.formatname binding. When messages to the WCF service that use the net.msmq binding are pending in the MSMQ queue, the WCF service will not automatically start.
This is by design. WAS is designed so that when a single IIS application pool has multiple WCF services that use mixed msmq binding types, the msmq.formatname service takes precedence, and the flag to restart the net.msmq service is set to ” no “. Therefore only the service that uses msmq.formatname will automatically start the w3wp process for that application pool when messages become available in the MSMQ queue.
The workaround is to use two separate application pools for your WCF services, separating the two different msmq bindings.

Article ID: 2974327 – Last Review: July 31, 2014 – Revision: 1.0


Applies to
  • Windows Communication Foundation 3.0
  • Windows Communication Foundation 3.5
  • Windows Communication Foundation 4
  • Windows Communication Foundation 4.5
  • Microsoft Internet Information Services 7.0
  • Microsoft Internet Information Services 7.5
  • Microsoft Internet Information Services 8.0
  • Microsoft Internet Information Services 8.5

Read More:
WCF Service does not start automatically when messages are available through MSMQ

Your mailbox can’t be accessed or has limited functionality after a mailbox plan is changed from Kiosk to another plan in Office 365 dedicated/ITAR

In Microsoft Office 365 dedicated/ITAR, you can’t access your mailbox, or the mailbox experiences limited functionality of a specific feature. This behavior occurs after a mailbox plan is changed from Exchange Online Kiosk D to Exchange Online Plan 1D or Exchange Online Plan 2D.
This behavior occurs because the client access settings aren’t set for the Exchange Online Plan 1D or Exchange Online Plan 2D in the mailbox plan provisioning process.
The provisioning process that uses the SetMailboxType script is replaced by the mailbox plan provisioning process in Microsoft Office 365 dedicated/ITAR. This process includes the 13.1 version (for Exchange Server 2010) and the 2013 version (for Exchange Server 2013).

The mailbox plan provisioning process uses the following client access settings, depending on the plan class.

Collapse this tableExpand this table

Plan class Customer managed settings Settings managed by the mailbox plan provisioning process only
Standard (Exchange Online Plan 1D or Exchange Online Plan 2D plans)
  • MAPIBlockOutlookVersions
  • ActiveSyncEnabled
  • EWSEnabled
  • IMAPEnabled
  • MAPIEnabled
  • OWAEnabled
  • POPEnabled
  • OWAMailboxPolicy
Exchange Online Kiosk D
  • ActiveSyncEnabled
  • OWAEnabled
  • POPEnabled
  • MAPIBlockOutlookVersions
  • EWSEnabled
  • IMAPEnabled
  • MAPIEnabled
  • OWAMailboxPolicy

Notes

  • For the Exchange Online Plan 1D and Exchange Online Plan 2D plans, all settings are customer managed. Therefore, no changes are made to these settings when you move to these plans.
  • For the Exchange Online Kiosk D plan, several settings are fully managed by the mailbox plan provisioning process. These settings are maintained on each run of the script. Customer managed settings aren’t changed. 

Changes made by the mailbox plan provisioning process

The mailbox plan provisioning process makes changes to a mailbox object in the following scenarios.

Scenario 1: Initial processing of a mailbox (for Exchange Server 2010 only)

The mailbox plan provisioning process sets all access and quota settings to their default values for both customer managed and mailbox plan provisioning process-managed clients. In Exchange Server 2013, Microsoft Managed Services Service Provisioning Provider (MMSSPP) applies the client access and quota settings when the mailbox is created.

Scenario 2: Changes of the plan in the plan class (Exchange Online Plan 1D to Exchange Online Plan 2D)

Only the quota is updated (if it’s different) because client access settings that are customer managed aren’t updated.

Scenario 3: Changes of the plan class

  • Exchange Online Plan 1D or Exchange Online Plan 2D to Exchange Online Kiosk D

    The mailbox quota is updated (if it’s different). The client access settings that are managed by the mailbox plan provisioning process are updated.

  • Exchange Online Kiosk D to Exchange Online Plan 1D or Exchange Online Plan 2D

    The mailbox quota is updated (if it’s different). No client access settings are changed because all the settings are customer managed.

Scenario 4: Management of the Exchange Online Kiosk D plan settings

The Mailbox Plans provisioning process sets any of the settings to the plan defaults if there are any changes.

Scenario 5: Mailbox moved from on-premises Lotus Notes environment (Exchange Server 2010 only)

The mailbox plan provisioning process sets all access and quota settings to their default values for both customer-managed and mailbox plan provisioning process-managed clients. In Exchange Server 2013, MMSSPP applies the quota and client access settings when the mailbox is created.

Scenario 6: Mailbox moved from on-premises Exchange environment

The mailbox quota is set. Any other client access settings that are managed by the mailbox plan provisioning process are updated.

This behavior is by design.

Article ID: 2987640 – Last Review: July 30, 2014 – Revision: 1.0


Applies to
  • Microsoft Business Productivity Online Dedicated
  • Microsoft Business Productivity Online Suite Federal

Visit link:
Your mailbox can’t be accessed or has limited functionality after a mailbox plan is changed from Kiosk to another plan in Office 365 dedicated/ITAR

Auto-replies aren’t generated in an Office 365 dedicated High Availability (ANSI-D) environment

Consider the following scenario: 
  • In a Microsoft Office 365 dedicated High Availability (ANSI-D) environment, you set a mailbox to forward messages to an alternative recipient by using the ForwardingSMTPAddress parameter. That is, you set messages to be delivered to both the original recipient and the forwarded recipient.
  • You also set up an auto-reply of some type for the mailbox. For example, the auto-reply is a Microsoft Outlook rule or an out-of-office (OOF) message.

In this scenario, the message is forwarded as expected. However, the auto-reply isn’t generated.

In Office 365 dedicated ANSI-D, the XLOOP header limit for a given message is set to one (1). This issue occurs because the following forwarding or auto-reply options increase the XLOOP header value: These options can’t be used in combination. 
If you must use both message forwarding and an OOF message or an Outlook auto-reply rule, you should use the ForwardingAddress parameter instead of the ForwardingSMTPAddress parameter when you set up mailbox forwarding.

Note The ForwardingSMTPAddress parameter can take any valid SMTP address as an input. However, the ForwardingAddress parameter requires a Microsoft Exchange Server user object as its value. The object may be a mailbox-enabled user, a mail-enabled user, or a mail-enabled contact. If no such object exists in the Office 365 dedicated environment, you must create a new user or contact in Active Directory Domain Services (AD DS) for the on-premises environment and then synchronize to Office 365 through Microsoft Managed Services Service Provisioning Provider (MMSSPP). 

To set up mailbox forwarding to use an Exchange Server object, run the following cmdlets:

Set-Mailbox John@contoso.com –ForwardingSMTPAddress $NULL
Set-Mailbox John@contoso.com –ForwardingAddress Mike@wingtiptoys.com

Article ID: 2988783 – Last Review: July 30, 2014 – Revision: 1.0


Applies to
  • Microsoft Business Productivity Online Dedicated
  • Microsoft Business Productivity Online Suite Federal

Link:
Auto-replies aren’t generated in an Office 365 dedicated High Availability (ANSI-D) environment

Only OWA Light mode is available when you access an Office 365 dedicated/ITAR mailbox

When you use Internet Explorer 8 to access a Microsoft Office 365 dedicated/ITAR mailbox in Microsoft Exchange Server 2013, only Microsoft Outlook Web App (OWA) Light mode is available.

This is expected behavior. OWA Light mode is the only option that you have when you use Internet Explorer 8 in Exchange Server 2013.

For more information about browser support, see What’s new for Outlook Web App in Exchange 2013

(http://technet.microsoft.com/en-us/library/jj150522(v=exchg.150).aspx)

.

Article ID: 2987965 – Last Review: July 29, 2014 – Revision: 1.0


Applies to
  • Microsoft Business Productivity Online Dedicated
  • Microsoft Business Productivity Online Suite Federal

More here:
Only OWA Light mode is available when you access an Office 365 dedicated/ITAR mailbox

You can’t manage Send As and Send on Behalf permissions for shared mailboxes in the EAC in Office 365 dedicated/ITAR

When you sign in to the Exchange admin center (EAC) in Microsoft Office 365 dedicated/ITAR, you see limited options to set the permissions of a shared mailbox. The options to individually manage the “Send As” and “Send on Behalf” permissions are available for user mailboxes. However, only the option to manage full mailbox permissions are available for shared mailboxes.
This issue occurs because the “Send As” and “Send on Behalf” permissions can’t be managed in the EAC.
To work around this issue, add the “Send As” and “Send on Behalf” permissions by using Windows Remote PowerShell. To do this, follow the instructions on the following Microsoft TechNet website:
For more information about shared mailboxes, see the following Microsoft TechNet website:
Shared Mailboxes

(http://technet.microsoft.com/en-us/library/jj150498%28v=exchg.150%29.aspx)

Article ID: 2988058 – Last Review: July 29, 2014 – Revision: 1.0


Applies to
  • Microsoft Business Productivity Online Dedicated
  • Microsoft Business Productivity Online Suite Federal

Original post:
You can’t manage Send As and Send on Behalf permissions for shared mailboxes in the EAC in Office 365 dedicated/ITAR

Fatal error during installation of Microsoft Dynamics CRM 2013 Report Authoring Extensions

After attempting to install Microsoft Dynamics CRM 2013 Report Authoring Extensions, an error is received after installing the Windows Live ID Sign-In Assistant pre-requisite:

Microsoft Dynamics CRM Report Authoring Extension Setup

Action Microsoft.Crm.Setup.Common.Analyzer+CollectAction failed.

Fatal error during installation

Consider the following scenario:

An installation of Microsoft Dynamics CRM 2011 Report Authoring Extensions is attempted, however during installation the setup wizard throws an error during the Environment Check and/or User Input Check steps. After this, an installation of Microsoft Dynamics CRM 2013 Report Authoring Extensions is attempted as the wrong version had been attempted in the first installation.

Multiple version installations of Microsoft Dynamics CRM Report Authoring Extensions attempted on the same machine
To resolve this issue, a registry entry will need to be removed from the machine before proceeding with the Microsoft Dynamics CRM 2013 Report Authoring Extensions installation:

WARNING: Using Registry Editor incorrectly can cause serious problems that may require you to reinstall Windows. Microsoft cannot guarantee that problems resulting from the incorrect use of Registry  Editor can be solved. Use Registry Editor at your own risk.

1. Navigate to the Start Menu (or Windows key + R will perform steps 1 and 2)

2. In the search bar, type Run and hit enter

3. In the open lookup, type Regedit and hit enter

4. Expand the Windows Registry tree to the following registry directory:

HKLMSOFTWAREMicrosoftWindowsCurrentVersionInstallerUserDataS-1-5-18ComponentsEF1E6B4EFCDA2649B26A424D56DAACD

a. HKEY_LOCAL_MACHINE

 b. Software

 c. Microsoft

 d. Windows

 e. CurrentVersion

 f. Installer

 g. UserData

 h. S-1-5-18

 i. Components

j. 0EF1E6B4EFCDA2649B26A424D56DAACD

5. Examine the registry key ’0EF1E6B4EFCDA2649B26A424D56DAACD’ for multiple string value registry entries

 a. A single string value should be present in this directory – the scenario outlined in the symptom will result in two string registry entries being created.

6. Right-Click on the registry key 0EF1E6B4EFCDA2649B26A424D56DAACD and select Export

 a. Save the registry backup to a location on the local computer

7. Right-Click on the registry key 0EF1E6B4EFCDA2649B26A424D56DAACD and select Delete

 Note: This key is created during setup and will be recreated as part of the setup process

8. Start the Microsoft Dynamics CRM 2013 Report Authoring Extensions installation wizard

Note This is a “FAST PUBLISH” article created directly from within the Microsoft support organization. The information contained herein is provided as-is in response to emerging issues. As a result of the speed in making it available, the materials may include typographical errors and may be revised at any time without notice. See Terms of Use

(http://go.microsoft.com/fwlink/?LinkId=151500)

for other considerations.

Article ID: 2988630 – Last Review: July 28, 2014 – Revision: 1.0


Applies to
  • Microsoft Dynamics CRM 2011
  • Microsoft Dynamics CRM 2013
kbmbsmigrate kbsurveynew KB2988630

Continue Reading:
Fatal error during installation of Microsoft Dynamics CRM 2013 Report Authoring Extensions

"Lync cannot verify that the server is trusted for your sign-in address." message when you sign in to Lync 2010 by authenticating to Lync Online

When you sign in to Microsoft Lync 2010 by authenticating to the Microsoft Lync Online service, you receive the following message in a certificate trust dialog box:
Lync is attempting to connect to:

Autodiscover Service Address

Lync cannot verify that the server is trusted for your sign-in address. Connect anyway?

Collapse this imageExpand this image

This dialog box appears during sign-in or after you sign in.

This dialog box is a “Trust Model Dialog” box. It is displayed when you are connecting to a server that is unknown to Lync. Lync must have your permission to verify whether to trust this server. For example, in the earlier screen shot, domainName.contoso.com is the unknown server.

The dialog box may be displayed in the following scenarios:

  • During sign-in to Lync to connect to the Lync server

    This means that the name of the Lync server that you are trying to connect is not trusted yet. Therefore, Lync requests confirmation from you.

  • After sign-in to Lync to connect to Exchange server

    After you are signed in, Lync tries to connect to your Microsoft Exchange Server mail server. This connection is required to provide you with rich Lync features. If your Lync sign-in address differs from your Exchange address, the dialog box that has the prompt is displayed. Otherwise, the dialog box is not displayed.

Be aware that this is a security feature and is not an issue or a problem. Lync will not connect to any unknown server until you confirm that it is trusted.

We recommend that you verify the domain name that is displayed in the dialog box to verify that it is a trusted server that you want to connect to. After you decide to trust the server, follow these steps:
  1. In the dialog box, click to select the Always trust this server, do not show me this again check box.
  2. Click Connect.

After you perform these steps, the dialog box is no longer displayed when you connect to the server.

Important This section contains steps that tell you how to modify the registry. However, serious problems might occur if you modify the registry incorrectly. Therefore, make sure that you follow these steps carefully. For added protection, back up the registry before you modify it. Then, you can restore the registry if a problem occurs. For more information about how to back up and restore the registry, click the following article number to view the article in the Microsoft Knowledge Base:
322756

(http://support.microsoft.com/kb/322756/
)

How to back up and restore the registry in Windows

To prevent the dialog box from being displayed, you can edit the following REG_SZ registry value:

HKEY_CURRENT_USERSoftwareMicrosoftCommunicatorTrustModelData

To do this manually for one computer, follow these steps:

  1. Start Registry Editor.
  2. Locate, and then double-click the TrustModelData egistry value:

    HKEY_CURRENT_USERSoftwareMicrosoftCommunicatorTrustModelData

  3. Add the Fully Qualified Domain Name (FQDN) of the server-based computer that is displayed in the Trust Model Dialog to the existing value data that is listed in the TrustModelData registry value.

Important The value data for the TrustModelData registry value is known as Address of Record (AOR) information. An AOR entry is in the format of a Fully Qualified Domain Name (FQDN). Separate AOR entries will be listed in a comma delimited list that makes up the value data for the TrustModelData registry value. For example: contoso.com, adatum.com, server01.fourthcoffeee.com. All additional AOR entries should be preceded with a comma before they are added to the list.

Note If the user’s Exchange mailbox domain server address differs from the Lync sign-in domain server address, the Trust Model Dialog box may appear after the user signs in. Administrators can use this procedure to append the Exchange mailbox domain server address to the value data of the TrustModelData registry value.

There are no Windows Active Direcrory Group Policies that can be used to manage the Lync 2010 TrustModelData registry value. Group Policy for the Lync 2010 TrustModelData registry value can be managed through manual registry edits on the Windows client-based computer or automated registry edits that are administered globally on the network to the Windows client-based computers. The following is an example of these registry locations to update:

  • HKEY_CURRENT_USERPoliciesMicrosoftCommunicator
  • HKEY_LOCAL_MACHINEPoliciesMicrosoftCommunicator

Lync identifies unknown servers and domains by using the Lync Autodiscover service. For more information about the Lync Autodiscover service, visit the following Microsoft website:

Article ID: 2531068 – Last Review: July 28, 2014 – Revision: 7.0


Applies to
  • Microsoft Lync 2010
  • Microsoft Lync Online
kbqfe kbsurveynew kbexpertisebeginner kbexpertiseinter vkbportal231 vkbportal237 kbgraphic o365e o365p o365a o365m o365022013 o365 KB2531068

Read More:
"Lync cannot verify that the server is trusted for your sign-in address." message when you sign in to Lync 2010 by authenticating to Lync Online

How to troubleshoot issues that you may encounter when you use the Lync 2010 mobile client for Google Android

The Microsoft Lync 2010 mobile client for Google Android requires a Lync account from your company organization. If you aren’t sure whether you have a Lync account, contact your company system administrator or support team.

The Lync 2010 mobile client for Google Android smartphones isn’t supported on Android tablets or on other non-phone Android devices. For more information, go to the following Microsoft Knowledge Base article:

2691382

(http://support.microsoft.com/kb/2691382/
)

Android smartphone devices that are supported for use with Lync 2010 for Android

This article describes how to troubleshoot some common issues that you may encounter when you use the Lync 2010 mobile client for Google Android.

Collapse this imageExpand this image

Signing in to Lync 2010 on Google Android

Verify your password, account information, server settings, and client version

Collapse this imageExpand this image

  1. Make sure that you can sign in to Lync from a desktop by using Lync 2010, Microsoft Lync 2013, or Microsoft Lync for Mac 2011. If you can’t sign in from a regular desktop client, you probably can’t sign in to a mobile client.
  2. Make sure that you enter the correct password. If the password is incorrect, you’ll have to change it. For more information, go to the following Microsoft website:
  3. Make sure that you enter the correct account information. Unless your administrator has told you otherwise, you probably use the same account information to sign in to Microsoft Outlook, Microsoft SharePoint, and your work computer. If you can sign in to Lync from a desktop computer, use the same information to sign in to your mobile device.

    The following table describes the sign-in fields that are required for Android users, depending on where their Lync account is located and how their account information is set up.

    Collapse this tableExpand this table

    Lync account SIP address and UPN Required fields
    On-premises Lync server Same Sign-in address: SIP address
    User name: Blank
    On-premises Lync server Different Sign-in address: SIP address
    User name: UPN or domainusername
    Office 365 Same Sign-in address: SIP address
    User Name: Blank
    Office 365 Different Sign-in address: SIP address
    User name: UPN
  4. Verify whether Auto-detect server is On. Lync tries to determine your Lync server based on your sign-in address. If it can’t detect your Lync server, you may have to turn off Auto-detect server and specify the Lync server manually.

    If Auto-detect server is turned on but you still can’t sign in, try manually entering the internal and external discovery addresses. This doesn’t resolve the issue. However, if you can successfully sign in manually, this indicates that the Auto-detect server option isn’t set up correctly by your administrator.

    • For Lync Online users in Office 365:
      • Internal discovery address: https://webdir.online.lync.com/Autodiscover/autodiscoverservice.svc/Root
      • External discovery address: https://webdir.online.lync.com/Autodiscover/autodiscoverservice.svc/Root
    • For Lync on-premises users, contact your support team or system administrator for help to determinine your internal and external discovery address. In most cases, the internal and external discovery address should resemble the following:
      • Internal discovery address: https://lyncdiscover.lyncFE01.contoso.local/Autodiscover/autodiscoverservice.svc/Root
      • External discovery address: https://lyncdiscover.contoso.com/Autodiscover/autodiscoverservice.svc/Root


      Note
      To access the User name, Domain, Internal discovery address, and External discovery address fields, click Server Settings on the sign-in screen.

  5. Make sure that you’re using the latest version of the Lync 2010 mobile client for Google Android. Download the latest version from Google Play. If you receive a message that states the client version is blocked or not supported, contact your support team or administrator because the Lync server might not be set up yet for mobile clients.

Collapse this imageExpand this image

Connecting over Wi-Fi through an authenticating proxy

Collapse this imageExpand this image

If the Wi-Fi connection that’s used requires authentication before you connect, Lync may not connect because it can’t use the credentials to connect through a proxy. To work around this issue, connect through the mobile carrier’s data connection instead of through Wi-Fi.

Collapse this imageExpand this image

Connecting on a network that requires certificates

Collapse this imageExpand this image

If your organization requires certificates to connect to their Wi-Fi or corporate network, and you receive an error message from Lync about certificates being incorrect or missing, you may have to import certificates from your company. There are apps in the Google Play store for importing and managing certificates. Contact your support team or administrator for help.

Collapse this imageExpand this image

Additional help with specific features

Collapse this imageExpand this image

For guides, FAQ, and references to help you use the Lync 2010 mobile client on Google Android, go to the following Microsoft websites:

Collapse this imageExpand this image

Comparison with other mobile clients

Collapse this imageExpand this image

For a feature comparison of Lync 2010 mobile clients, go to the following Microsoft TechNet website:

Collapse this imageExpand this image

Sending logs to support

Collapse this imageExpand this image

When users experience an issue that affects the Lync 2010 mobile client for Google Android, they can send logs by email to the support team or administrator. To do this, follow these steps:

  1. On the Google Android device, after a user is signed in, tap Options on the Signing in tab. On the Options screen, tap Diagnostic logging, sign out, and then sign in again. (The screen shot for this step is listed below).

    Collapse this imageExpand this image

  2. Reproduce the issue, return to the Options screen, and then tap About Lync.
  3. Tap Send diagnostic logs, and then select a configured email account. (The screen shot for this step is listed below).

    Collapse this imageExpand this image

  4. In the To box, enter the recipient’s email address. For example, your personal email address or your technical support team’s alias. In the Subject box, enter a subject, and then tap Send. Logs are attached as a .zip file. (The screen shot for this step is listed below).

    Collapse this imageExpand this image

Note Make sure that Logging is set to ON before you try to reproduce the issue and send logs.

Collapse this imageExpand this image

The third-party products that this article discusses are manufactured by companies that are independent of Microsoft. Microsoft makes no warranty, implied or otherwise, about the performance or reliability of these products.

Microsoft provides third-party contact information to help you find technical support. This contact information may change without notice. Microsoft does not guarantee the accuracy of this third-party contact information.

Article ID: 2636313 – Last Review: July 25, 2014 – Revision: 22.0

o365 o365a o365p o365e kbgraphxlink o365m o365022013 kb3rdparty kbgraphic KB2636313

See original article:
How to troubleshoot issues that you may encounter when you use the Lync 2010 mobile client for Google Android

Page 1 of 72712345...102030...Last »

Recent Comments

    Archives

    Categories