KB Articles

Page 1 of 1,00112345...102030...Last »

"You do not have permission to access these records." when attempting to configure Microsoft Dynamics CRM for Office Outlook

When you attempt to configure Microsoft Dynamics CRM for Office Outlook and you have a custom security role, you encounter the following error:

“You do not have permission to access these records. Contact your Microsoft Dynamics CRM administrator.”

If the security role is assigned through team membership instead of being associated directly to the user, you encounter the following error:

“You do not have enough privileges to access the Microsoft Dynamics CRM object or perform the requested operation.”

The security role is missing sufficient read access to the Mailbox entity. 
Update the security role to include user level Read access to the Mailbox entity. If the role is assigned through team membership, the security role will need business unit level or higher access. 

1. Log into the Microsoft Dynamics CRM web application as a user with the System Administrator role.

2. From the navigation bar click Microsoft Dynamics CRM and then click Settings.

3. From the navigation bar click Settings and then click Administration. If you are using Microsoft Dynamics CRM 2015 or later, click Security instead of Administration.

4. Click Security Roles.

5. Open the security role granted to the user that encounters this issue.

6. Click the Business Management tab.

7. Click the circle to grant User level Read access to the Mailbox entity. This privilege can be located by finding the Mailbox entity and the intersection with the Read privilege.

8. Click Save and Close.

9. Attempt to configure Microsoft Dynamics CRM for Office Outlook again. 

The log file contains the following error with the Principal user reference matching your SystemUserId:

09:17:01|  Error| Exception : Principal user (Id=4294cbf9-7534-e311-8b6d-6c3be5a8f660, type=8) is missing prvReadMailbox privilege (Id=8e17de3a-5a69-479c-9535-1f7be75b2987)    at Microsoft.Crm.Application.Platform.ServiceCommands.PlatformCommand.XrmExecuteInternal()

   at Microsoft.Crm.Application.Platform.ServiceCommands.RetrieveCommand.Execute()

   at Microsoft.Crm.Caching.MailboxWebServiceCacheLoader.LoadCacheData(Guid key, IOrganizationContext context)

   at Microsoft.Crm.Caching.ClientCacheLoaderProxy`2.LoadCacheData(TKey key, IOrganizationContext context)

   at Microsoft.Crm.Caching.CrmMultiOrgCacheBase`2.CreateEntry(TKey key, IOrganizationContext context)

   at Microsoft.Crm.Caching.CrmMultiOrgCacheBase`2.LookupEntry(TKey key, IOrganizationContext context)

   at Microsoft.Crm.Application.Outlook.Config.OutlookConfigurator.InitializeMapiStoreForFirstTime()

   at Microsoft.Crm.Application.Outlook.Config.OutlookConfigurator.Configure(IProgressEventHandler progressEventHandler)

   at Microsoft.Crm.Application.Outlook.Config.ConfigEngine.Configure(Object stateInfo)

If the user is a member of a team that only has user level Read access to the Mailbox entity and they do not have a security role assigned directly to their user record with user level Read access to the Mailbox entity, the log file contains the following error with the Owner Id and Calling User reference matching your SystemUserId:

17:16:47|  Error| Exception : SecLib::AccessCheckEx failed. Returned hr = -2147187962, ObjectID: 7f27247a-dda1-e411-80d9-fc15b4285da4, OwnerId: 4294cbf9-7534-e311-8b6d-6c3be5a8f660,  OwnerIdType: 8 and CallingUser: 4294cbf9-7534-e311-8b6d-6c3be5a8f660. ObjectTypeCode: 9606, objectBusinessUnitId: 8bce1ea5-1e75-e411-80cf-c4346bac89f4, AccessRights: ReadAccess  
Server stack trace:
   at System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime operation, ProxyRpc& rpc)
   at System.ServiceModel.Channels.ServiceChannel.Call(String action, Boolean oneway, ProxyOperationRuntime operation, Object[] ins, Object[] outs, TimeSpan timeout)
   at System.ServiceModel.Channels.ServiceChannelProxy.InvokeService(IMethodCallMessage methodCall, ProxyOperationRuntime operation)
   at System.ServiceModel.Channels.ServiceChannelProxy.Invoke(IMessage message)

Exception rethrown at 0:
   at System.Runtime.Remoting.Proxies.RealProxy.HandleReturnMessage(IMessage reqMsg, IMessage retMsg)
   at System.Runtime.Remoting.Proxies.RealProxy.PrivateInvoke(MessageData& msgData, Int32 type)
   at Microsoft.Xrm.Sdk.IOrganizationService.Retrieve(String entityName, Guid id, ColumnSet columnSet)
   at Microsoft.Xrm.Sdk.WebServiceClient.OrganizationWebProxyClient.<>c__DisplayClass4.b__3()
   at Microsoft.Xrm.Sdk.WebServiceClient.WebProxyClient`1.ExecuteActionTResult(Func`1 action)
   at Microsoft.Xrm.Sdk.WebServiceClient.OrganizationWebProxyClient.RetrieveCore(String entityName, Guid id, ColumnSet columnSet)
   at Microsoft.Xrm.Sdk.WebServiceClient.OrganizationWebProxyClient.Retrieve(String entityName, Guid id, ColumnSet columnSet)
   at Microsoft.Crm.Application.SMWrappers.ClientOrganizationServiceProxyBase.Retrieve(String entityName, Guid id, ColumnSet columnSet)
   at Microsoft.Crm.Application.Outlook.Config.ServerInfo.LoadMailboxInfo(IClientAuthProvider`1 orgAuthProvider)
   at Microsoft.Crm.Application.Outlook.Config.ServerInfo.LoadUserInfo(IClientAuthProvider`1 orgAuthProvider)
   at Microsoft.Crm.Application.Outlook.Config.ServerInfo.Initialize(Uri discoveryUri, OrganizationDetail selectedOrg, String displayName, Boolean isPrimary, IClientAuthProvider`1 authenticatedProvider)
   at Microsoft.Crm.Application.Outlook.Config.ServerForm.LoadDataToServerInfo()
   at Microsoft.Crm.Application.Outlook.Config.ServerForm.b__3(Object sender, DoWorkEventArgs e)
   at System.ComponentModel.BackgroundWorker.OnDoWork(DoWorkEventArgs e)
   at System.ComponentModel.BackgroundWorker.WorkerThreadStart(Object argument)

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: 2899051 – Last Review: July 1, 2015 – Revision: 2.0


Applies to
  • Microsoft Dynamics CRM 2013
  • CRM Online via Office 365 E Plans
  • Microsoft Dynamics CRM Online Professional Plus
  • Microsoft Dynamics CRM Online Professional Edition
  • Microsoft Dynamics CRM 2015
kbmbsmigrate kbsurveynew KB2899051

Read More:
"You do not have permission to access these records." when attempting to configure Microsoft Dynamics CRM for Office Outlook

“Invalid Mailbox Type” error in ODBC Import Report when you migrate Lotus Notes users to Office 365 Dedicated/ITAR

When you schedule an on-boarding migration of Lotus Notes users to Office 365 Dedicated/ITAR, you receive an ODBC Import Report that displays the following error message for one or more users:
Note “On-boarding” is the process of moving mailboxes from an on-premises mail system to Exchange Online in Microsoft Office 365.
This problem occurs if the mailbox type value that is specified for the user in the scheduling database does not match any of the values that are allowed by the MOVE tool.
To resolve this problem, make sure that you are using only allowed values for users in your scheduling database. These values do not exactly match the mailbox provisioning strings syntax that is used by MMSSPP in your provisioning extension attribute. For example, “MBX=EX;TYPE=EP1D” can be used in your MMSSPP provisioning attribute, but it is not allowed by MOVE. Instead, the entry in MOVE should be only “EX” (without the quotation marks). Refer to the following table for the typical mailbox codes that are allowed in MOVE scheduling databases.

Collapse this tableExpand this table

Code Size (in MB)
DW
ST
EX
50MB
200MB
500MB
1GB
2GB
3GB
4GB
5GB
10GB
15GB
20GB
25GB
512
5120
25600
50
200
500
1024
2048
3072
4096
5120
10240
15360
20480
25600

Note Although these are the most frequently allowed values in MOVE, your organization may have values that are different from those that are listed here. This may be true if you have requested any customized changes to the list.

Article ID: 3074646 – Last Review: July 1, 2015 – Revision: 2.2


Applies to
  • Microsoft Business Productivity Online Dedicated
  • Microsoft Business Productivity Online Suite Federal
vkbportal226 kbgraphic kbgraphxlink KB3074646

View article:
“Invalid Mailbox Type” error in ODBC Import Report when you migrate Lotus Notes users to Office 365 Dedicated/ITAR

“Not matched in NAB(s)” error when you schedule a Lotus Notes user for migration to Office 365 dedicated/ITAR

You cannot schedule a user for migration from Lotus Notes to Microsoft Office 365 Dedicated/ITAR in the MOVE tool. The Scheduling Report or ODBC Import Report displays the following error message for the user:
This problem occurs for any of the following reasons:
  • The SMTP address in your scheduling database contains blank spaces. For example, the address might be “user@contoso.com ” (blank spaces at the end). This situation can prevent MOVE from matching the user to the directory entry in your Notes Address Book (NAB).
  • In the user entry in your NAB, the SMTP address in the InternetAddress field might not match the one that is entered in your scheduling database.
  • The user entry in your NAB might have Reader fields applied that prevent replication of the entry to the Microsoft Online copy of your NAB that is used by MOVE.
  • The directory entry for the user might not be replicated to all NAB copies that Microsoft Online copies from.
  • The Microsoft Online copy of your NAB that is used by MOVE might be out-of-date.
To resolve this problem, determine whether the user account is configured correctly and is successfully replicated to the Microsoft Online copy of your NAB. To do this, follow these steps:
  1. Examine your scheduling database to verify that the SMTP address is spelled correctly and contains no blank spaces.
  2. Locate the directory entry for the user in your NAB, and then verify that the InternetAddress field is populated correctly and matches the SMTP address of the user that you are trying to schedule.

    Note This should be in the “user@contoso.com” format, not in the “User/Org/Contoso” format.

  3. Examine the permissions tab of the document properties for the user in your NAB. Make sure that the All readers and above option is selected, or that */MicrosoftOnline is allowed to read the document.
  4. Determine which other servers your NAB is replicating to, and make sure that there are no local replication issues that prevent the missing user from populating in the NAB on those servers.

    For example, assume that the user appears in the NAB on Server1 but not in the NAB replicas on Server2 and Server3, and also that MOVE is set to replicate with Server3. In this situation, the Microsoft Online copy of the NAB will not contain the user.

  5. Check the replication history for the NAB on the server that is designated for replication to the Microsoft Online server. If the replication history is out-of-date, escalate the case to Microsoft Online Services Support by online submission

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

    or by telephone

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

    for investigation.

    Note Because MOVE is typically configured to replicate with multiple NABs in different customer departments or subsidiaries, you should provide details about which NAB is not replicating and which server MOVE should be replicating from.

Article ID: 3074634 – Last Review: July 1, 2015 – Revision: 2.0


Applies to
  • Microsoft Business Productivity Online Dedicated
  • Microsoft Business Productivity Online Suite Federal
vkbportal226 kbgraphic kbgraphxlink KB3074634

See original article:
“Not matched in NAB(s)” error when you schedule a Lotus Notes user for migration to Office 365 dedicated/ITAR

Event IDs 5788 and 5789 occur on a Windows-based computer

You may experience one of the following problems:
  • On Windows Vista and later versions, you receive the following error message during interactive logon:

    The security database on the server does not have a computer account for this workstation trust relationship.

  • Interactive logons with domain-based accounts don’t work. Only logons with local accounts are functioning.
  • The following event messages are logged in the System log:

    Event Type: Error
    Event Source: NETLOGON
    Event Category: None
    Event ID: 5788
    Computer: ComputerName
    Description:
    Attempt to update Service Principal Name (SPN) of the computer object in Active Directory failed. The following error occurred: <Detailed error message that varies, depending on the cause.>

    Event Type: Error
    Event Source: NETLOGON
    Event Category: None
    Event ID: 5789
    Computer: Computer
    Description:
    Attempt to update DNS Host Name of the computer object in Active Directory failed. The following error occurred: <Detailed error message that varies, depending on the cause.>

    Note Detailed error messages for these events are listed in the “Cause” section.

This behavior occurs when a computer tries but does not write to the dNSHostName and servicePrincipalName attributes for its computer account in an Active Directory Domain Services (AD DS) domain.

A computer tries to update these attributes if the following conditions are true:

  • Immediately after a Windows-based computer joins a domain, the computer tries to set the dNSHostName and servicePrincipalName attributes for its computer account in the new domain.
  • When the security channel is established on a Windows-based computer that is already a member of an AD DS domain, the computer tries to update the dNSHostName and servicePrincipalName attributes for its computer account in the domain.
  • On a Windows-based domain controller, the Netlogon service tries to update the servicePrincipalName attribute every 22 minutes.

There are two possible causes of the update failures:

  • The computer does not have sufficient permission to complete an LDAP modify request of the dNSHostName or servicePrincipalName attributes for its computer account.

    In this case, the error messages that correspond to the events that are described in the “Symptoms” section are as follows:

    • Event 5788
    • Event 5789

      The system cannot find the file specified.

  • The primary DNS suffix of the computer does not match the DNS name of the AD DS domain of which the computer is a member. This configuration is known as a “Disjoint namespace.”

    For example, the computer is a member of the Active Directory domain contoso.com. However, its DNS FQDN name is member1.nyc.contoso.com. Therefore, the primary DNS suffix does not match the Active Directory domain name.

    The update is blocked in this configuration because the prerequisite write validation of the attribute values fails. The write validation fails because, by default, the Security Accounts Manager (SAM) requires that a computer’s primary DNS suffix matches the DNS name of the AD DS domain of which computer is a member.

    In this case, the error messages that correspond to the events that are described in the “Symptoms” section are as follows:

    • Event 5788

      The attribute syntax specified to the directory service is invalid.

    • Event 5789

      The parameter is incorrect.

To resolve this problem, find the most likely cause as described in the “Cause” section. Then, use the resolution that is appropriate for the cause.

Resolution for Cause 1

To resolve this issue, you must make sure that the computer account has sufficient permissions to update its own computer object.

In the ACL Editor, make sure that there is an access control entry (ACE) for the trustee account “SELF” and that it has “Allow” access for the following extended rights:

  • Validated write to DNS host name
  • Validated write to service principal name

Then, verify any Deny permissions that may apply. Excluding the group memberships of the computer, the following trustees also apply to the computer:

  • Everyone
  • Authenticated Users
  • SELF

The ACEs that apply to these trustees may also deny access to write to attributes, or they may deny the “Validated write to DNS host name” or “Validated write to service principal name” extended rights.

Resolution for Cause 2

To resolve this issue, use one of the following methods, as appropriate:

  • Method 1: Correct an unintentional disjoint namespace

    If the disjoint configuration is unintentional, and if you want to revert to a contiguous namespace, use this method.

    For more information about how to revert to a contiguous namespace on Windows Server 2003, see the following Microsoft TechNet article:

    For Windows Server 2008 and for Windows Vista and later versions, see the following Microsoft TechNet article:

  • Method 2: Verify that the disjoint namespace configuration is working correctly

    Use this method, if you want to keep the disjoint namespace. To do this, follow these steps to make some configuration changes to resolve the errors.

    For more information about how to verify that the disjoint namespace is working correctly on Windows Server 2003 R2, Windows Server 2003, Windows Server 2003 with Service Pack 1 (SP1), and Windows Server 2003 with Service Pack 2 (SP2), see the following Microsoft TechNet article:

    For more information about how to verify that the disjoint namespace is working correctly on Windows Server 2008 R2 and Windows Server 2008, see the following Microsoft TechNet article: 
    By extending the example that is mentioned in the last major bullet point in the “Cause” section, you would add “nyc.contoso.com” as an allowed suffix to the attribute.

Older versions of this article mentioned changing the permissions on the computer objects to enable general write access to resolve this problem. This was the only approach that existed in Windows 2000. However, it is less secure than using msDS-AllowedDNSSuffixes.

msDS-AllowedDNSSuffixes restricts the client from writing arbitrary SPNs into Active Directory. The “Windows 2000 method” enables the client to write SPNs that block Kerberos from working with other important servers (create duplicates). When you use msDS-AllowedDNSSuffixes, SPN collisions such as those can occur only when the other server has the same host name as the local computer.

A network trace of the response to the LDAP modify request displays the following information: 

win:17368, src: 389 dst: 1044

LDAP: ProtocolOp: ModifyResponse (7)

LDAP: MessageID

LDAP: ProtocolOp = ModifyResponse

LDAP: Result Code = Constraint Violation

LDAP: Error Message = 0000200B: AtrErr: DSID-03151E6D

In this network trace, 200B hexadecimal is equal to 8203 decimal.

The net
helpmsg 8203
command returns the following information:

The attribute syntax specified to the
directory service is invalid.” Network Monitor 5.00.943 displays the
following result code: “Constraint Violation.” Winldap.h maps error 13 to
“LDAP_CONSTRAINT_VIOLATION.

The DNS domain name and the Active Directory domain name can differ if one or more of the following conditions are true: Domains in an Active Directory forest that do not have the same hierarchical domain name are in a different domain tree. When different domain trees are in a forest, the root domains are not contiguous. However, this configuration does not create a disjoint DNS namespace. You have multiple DNS or even Active Directory DNS root domains. A disjoint namespace is characterized by a difference between the primary DNS suffix and the Active Directory domain name of which the computer is a member.

Disjoint namespace can be used with caution in some scenarios. However, it is not supported in all scenarios.

Article ID: 258503 – Last Review: June 29, 2015 – Revision: 19.0


Applies to
  • Windows Server 2008 Service Pack 2
  • Windows Vista Service Pack 2
  • Windows 7 Service Pack 1
  • Microsoft Exchange Server 2003 Service Pack 2
  • Microsoft Windows XP Service Pack 3
  • Microsoft Windows 2000 Advanced Server
  • Microsoft Windows 2000 Professional Edition
  • Microsoft Windows 2000 Server
  • Windows Server 2012 R2 Datacenter
  • Windows Server 2012 R2 Essentials
  • Windows Server 2012 R2 Standard
  • Windows Server 2012 Datacenter
  • Windows Server 2012 Essentials
  • Windows Server 2012 Standard
  • Windows Server 2012 Foundation
kbdns kberrmsg kbprb KB258503

Visit link:
Event IDs 5788 and 5789 occur on a Windows-based computer

Using WAN Optimization Controller or Traffic/Inspection devices with Office 365

Summary

Microsoft Office 365 does not require you to use WAN Optimization Controller devices (also known as WAN acceleration and caching devices) or traffic shaping/inspection devices (also known as packet shaping/inspection devices), nor can we comment on the effectiveness of these solutions. Customers may decide to use such devices to increase performance under conditions of high latency or low bandwidth for Microsoft Exchange Online and Microsoft SharePoint Online. We advise customers to use their discretion in deploying these devices with Office 365, whether in multi-tenant (MT), dedicated (D), or ITAR service configurations.

Microsoft does not offer first-party technical customer support for WAN Optimization Controller (WOC) devices. As with other network infrastructure equipment, we do not test the use of these devices with Office 365 to make sure that they work, nor do we take any responsibility for making sure that they continue to work as part of regular service updates. Customers should work directly with their WOC vendors to receive technical support.

During support incidents, we do require customers to inform us if they are using WOC devices. We also require that customers have an easy way to bypass the WAN optimization or traffic shaping/inspection services for Office 365. When we try to resolve a customer service issue in Office 365, we may ask that these devices be put in bypass mode before we continue with diagnosis and issue resolution. By bypass mode, we mean any combination of network or device configuration that logically or physically removes the device from the infrastructure path between the customer and Office 365.

More Information

Office 365 dedicated/ITAR customers can install and use WOC devices together with their service at their own discretion. The devices can be installed in the edge site that is used to interconnect a customer’s private network with the data networking presence that is provided by Microsoft. (In this case, the edge site is a third-party-carrier meet-me room MMR facility that is associated with a carrier hotel or anchor site.) Be aware that this option is available only for Office 365 dedicated/ITAR deployments and not for the multi-tenant service. To achieve the same results, some vendors offer the option of deploying their WOC in the customer’s data center instead of in the edge site. Because the use of WOC devices can potentially affect the reliability of the Office 365 service, customers must agree to the following terms when they opt to use these devices:

  • If a customer’s support request involves diagnosing a service access issue, the customer must disclose WOC devices that are being used when he or she contacts Microsoft Online Services Support by online submission (see http://support.microsoft.com/kb/2694621

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

    ) or by telephone (see http://support.microsoft.com/kb/2573289

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

    ).

  • If a WOC device is found to affect the performance or availability of Office 365 service components during troubleshooting by Microsoft, we may ask the customer to bypass the WOC device to make sure that service availability is maintained.
  • Before a customer re-enables a WOC device, he or she must directly engage the technical support resources of the device vendor to investigate issues that are caused by the device.
  • Any event that adversely affects service and that we determine to be caused by the existing WOC device will be identified as a Service Level Agreement (SLA) exclusion.

For all customer deployments, Microsoft does not provide first-party technical customer support for the integration and use of WOC or traffic shaping/inspection devices with Office 365 (in multi-tenant, dedicated, and ITAR configurations). Our position and rationale are as follows:

  • We cannot provide proactive support for these devices or for related third-party software that we do not control. These devices sit between the client and our servers. They affect every network communication and can potentially affect our service. We cannot take responsibility for any issues caused by these devices.
  • Because we cannot diagnose the devices directly, we may ask to bypass them during support diagnosis or troubleshooting. If bypassing the WOC devices fixes a problem, the customer must work with the device manufacturer to obtain a long-term resolution (such as a code update) and to then re-enable the device.
  • We realize that our customers may have to deploy such devices. But because of their complexity, these devices remain the customer’s responsibility when any issues arise. 

In summary, WOC or traffic shaping/inspection devices are considered part of the customer’s on-premises landscape, and if they are used, any related issues are the customer’s responsibility. As we continue to improve the Office 365 service, changes can potentially affect the performance of these devices. It is the responsibility of the customer and the device manufacturer to make any necessary modifications to support our service changes.

Article ID: 2690045 – Last Review: June 29, 2015 – Revision: 16.0


Applies to
  • Microsoft Business Productivity Online Dedicated
  • Microsoft Business Productivity Online Suite Federal
  • Microsoft Office 365
  • Skype for Business Online
vkbportal226 o365 o365022013 KB2690045

Contact us for more help

Connect with Answer Desk for expert help.

Read More:
Using WAN Optimization Controller or Traffic/Inspection devices with Office 365

Users of Exchange Server 2013 or Exchange Online can’t open public folders or shared mailboxes on an Exchange 2010 or Exchange 2007 server

Consider the following two scenarios:
  • You have an on-premises deployment, in which Microsoft Exchange Server 2013 is installed in an existing Exchange Server 2010 or Exchange Server 2007 organization.
  • You have a hybrid deployment of Exchange Server and Exchange Online in Office 365, in which the hybrid server is running Exchange Server 2013.

In either of these scenarios, users who have a mailbox on Exchange 2013 or Exchange Online are constantly prompted for credentials. If the users click Cancel when they are prompted for credentials, they can access their mailboxes. However, they can’t open the following resources:

  • A shared mailbox or a shared calendar of the mailbox in Exchange Server 2010 or Exchange Server 2007
  • A public folder in Exchange Server 2010 or Exchange Server 2007

Additionally, users receive the following error message:

Cannot expand the folder. Microsoft Exchange is not available. Either there are network problems or the Exchange server is down for maintenance.

This issue occurs if the Logon network security option in Microsoft Outlook is set to Anonymous Authentication. If you manually change the setting to something else, the Autodiscover service will change it back to Anonymous Authentication. (Refer the following screen shot)

Collapse this imageExpand this image

If Outlook Anywhere is configured by using one of the following combinations, the Autodiscover service sends “Anonymous” to the Outlook clients as the Logon network security option:

  • “ExternalHostName” is set, and “ExternalClientAuthenticationMethod” is set to Negotiate. (Refer the following screen shot)

    Collapse this imageExpand this image

  • “InternaClientlAuthenticationMethod” is set to Negotiate, and “InternalClientRequireSSL” is set to True. (Refer the following screen shot)

    Collapse this imageExpand this image

To resolve this issue, follow these steps:
  1. Run the Get-OutlookAnywhere cmdlet to verify the Outlook Anywhere settings on Exchange Server 2013 Client Access servers. The following example retrieves all Outlook Anywhere settings on the Exch1 server.
    Get-OutlookAnywhere -Server Exch1
  2. If “ExternalHostName” is set, and “ExternalClientAuthenticationMethod” is Negotiate, change “ExternalClientAuthenticationMethod” to something other than Negotiate. The following example sets “ExternalClientAuthenticationMethod” to NTLM for the Exch1 server.
    Get-OutlookAnywhere -Server Exch1| Set-OutlookAnywhere -ExternalClientAuthenticationMethod NTLM
  3. If “InternaClientlAuthenticationMethod” is set to Negotiate, and “InternalRequireSSL” is True, change “InternalClientAuthenticationMethod” to something other than Negotiate, or change “InternalRequireSSL” to False. The following example sets “InternalClientAuthenticationMethod” to NTLM for the Exch1 server:
    Get-OutlookAnywhere -Server exch1 | Set-OutlookAnywhere -InternalClientAuthenticationMethod NTLM

    The following example sets “InternalRequireSSL” to False for the Exch1 server:

    Get-OutlookAnywhere -Server exch1 | Set-OutlookAnywhere -InternalClientsRequireSSL $False
  4. The new settings should be applied on the Outlook clients the next time that they send a request to the Autodiscover service. Or, you can manually change the settings.

Article ID: 2834139 – Last Review: June 25, 2015 – Revision: 8.0


Applies to
  • Microsoft Exchange Server 2013 Enterprise
  • Microsoft Exchange Server 2013 Standard
  • Microsoft Exchange Online
kbsurveynew kbtshoot kbexpertiseinter o365 o365a o365e o365m o365022013 hybrid kbgraphxlink o365p KB2834139

More:
Users of Exchange Server 2013 or Exchange Online can’t open public folders or shared mailboxes on an Exchange 2010 or Exchange 2007 server

Favorites folders are missing after you migrate mailboxes to Exchange Server 2013 in Office 365 Dedicated

unable to retrieve full-text content

Read more here:
Favorites folders are missing after you migrate mailboxes to Exchange Server 2013 in Office 365 Dedicated

"The Microsoft Exchange administrator has made a change that requires you quit and restart Outlook" error when you try to access a moved mailbox in Office 365 dedicated/ITAR

After your mailbox is moved to a computer that’s running Microsoft Exchange Server 2010 or Exchange Server 2013 in Microsoft Office 365 dedicated/ITAR, you cannot access the mailbox. You may also receive the following error message in Microsoft Outlook:

The Microsoft Exchange administrator has made a change that requires you quit and restart Outlook.

Collapse this imageExpand this image

In Microsoft Outlook Web App (OWA), this notification resembles the following:

Your mailbox appears to be unavailable. Try to access it again in 10 seconds. If you see this error again, contact your helpdesk.

Collapse this imageExpand this image

This issue occurs if one or more of the following conditions are true:
  • The mailbox is moved to a new Exchange site or forest. This includes its being moved to the Microsoft Exchange High Availability Topology infrastructure (ANSI-D).
  • Changes are made to public folder database.
  • Changes are made to the Exchange server endpoint.
  • Lync isn’t restarted after the mailbox is moved or after the Exchange server endpoint is changed.
  • You are running an older version of the Outlook client.

Note It’s expected that you are prompted to restart Outlook if changes are made to the public folder databases, to the Exchange server endpoint for the primary mailbox, or to any additional mailboxes that are associated with the profile. Additional mailboxes include those mailboxes to which you have full access or folder-level permissions.

By design, the mailbox remains online when it’s moved to Exchange Server 2010 or Exchange Server 2013 or when it’s moved between Exchange servers. This behavior lets you access the mailbox during the move process. After the move process is complete, you are prompted to restart Outlook or to log off from or on to OWA if the server is in a new Exchange site or forest. This behavior makes sure that the client starts to use the correct Exchange endpoint for all connections.

If changes are made to the Exchange server endpoint, or if public folder databases that are referenced by the current Exchange database are changed, it’s also expected that you’re prompted to restart Outlook.

If you continue to be prompted to restart Outlook client, follow these steps:

  1. Make sure that you restart Lync or Skype for Business if your mailbox was recently moved or if a change was made to the Exchange endpoint.
  2. Confirm that you have the most recent update for Outlook. Updated information and links to the most recent updates for Office 365 are available at Outlook Updates

    (https://technet.microsoft.com/en-us/library/dn803988(v=office.14).aspx)

    .

  3. If steps 1 and 2 don’t resolve the issue, enable Outlook logging. Instructions are available at What is the Enable logging (troubleshooting) option?

    (https://support.office.com/en-US/article/What-is-the-Enable-logging-troubleshooting-option-0FDC446D-D1D4-42C7-BD73-74FFD4034AF5)

  4. After the issue is captured when you enable logging, you should submit an escalation to Microsoft Online Services Support for investigation. You should include the following details:
    • Outlook logs
    • Approximate number of times that the prompt is received
    • Time and date of the most recent occurrence
    • Action that was taken just before the prompt was received. For example: 
      • At the first start of Outlook 
      • After you sent email 
      • While checking an address book entry

Article ID: 2591913 – Last Review: June 23, 2015 – Revision: 11.0


Applies to
  • Microsoft Business Productivity Online Dedicated
  • Microsoft Business Productivity Online Suite Federal
  • Microsoft Exchange Online
vkbportal226 kbgraphic kbgraphxlink KB2591913

Read the original:
"The Microsoft Exchange administrator has made a change that requires you quit and restart Outlook" error when you try to access a moved mailbox in Office 365 dedicated/ITAR

UM-enabled mailbox migration to Exchange Online fails

Mailbox ‘USER‘ in the source forest is currently enabled for Unified Messaging but it can’t be enabled for Unified Messaging in the target forest for the following reason: Unified Messaging isn’t available in the target forest. Please fix the problem or disable the mailbox for Unified Messaging before you try the operation again.
    + CategoryInfo          : InvalidArgument: (USER:MailboxOrMailUserIdParameter) New-MoveRequest, RecipientTask
   Exception
    + FullyQualifiedErrorId : Server=Server,RequestId=RequestId,TimeStamp=TimeStamp FailureCategory=Cmdlet-RecipientTaskException xxxxxxxx,Microsoft.Exchange.Management.RecipientTasks.
  NewMoveRequest

Original post:
UM-enabled mailbox migration to Exchange Online fails

Error creating Service Activities from the Service Calendar in Microsoft Dynamics CRM 2015

Users may receive an error while creating a Service Activity from the Service Calendar, however the user can create the Service Activity from Activities in CRM Online.  

An error has occurred. Try this action again. If the problem continues, check the Microsoft Dynamics CRM Community for solutions or contact your organization’s Microsoft Dynamics CRM Administrator. Finally, you can contact Microsoft support

When creating a Service Activity directly from the Service Calendar, it is required to have the Scheduled Start, Scheduled End, and Scheduled Duration fields on the Service Activity form.

1. Login to the CRM online organization.

2. Navigate to Settings > Customizations > Customize the System

3. Expand Entities and go to Service Activity

4. Open the Main Form of Service activity and verify each one of them are present on the Form: Scheduled Start, Scheduled End and Scheduled Duration

5. Save the changes and Publish the customizations

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: 3074562 – Last Review: June 22, 2015 – Revision: 3.1


Applies to
  • Microsoft Dynamics CRM Online Professional Edition

View article:
Error creating Service Activities from the Service Calendar in Microsoft Dynamics CRM 2015

Page 1 of 1,00112345...102030...Last »

Recent Comments

    Archives

    Categories