We have CRM 2016 On-premise (IFD Configured) and SharePoint 2016 On-premise (with SSL) . We are trying to enable server based SharePoint integration for this.
The place where we started was from the Microsoft article https://technet.microsoft.com/en-us/library/dn949332.aspx#BKMK_Setup
Now we are struggling with the running the powershell command on the CRM server
.\CertificateReconfiguration.ps1 -certificateFile c:\Personalcertfile.pfx -password personal_certfile_password -updateCrm -certificateType S2STokenIssuer -serviceAccount contoso\CRMAsyncService -storeFindType FindBySubjectDistinguishedName
It gives the error
The service accounts are given permission on the Certificate.
Could be a basic question- but from the powershell command that has to be run, would that need a new pfx file or does it have to be the certificate that was used while configuring IFD for CRM?
Ignoring this error tried enabling the SP integration but it popped out an error saying site Invalid (and no more details). Event viewer pointed to CRM Plugin error on 'ValidateSharePointSite'
Related
I have created an add-in and Azure app similar to that shown in the Graph API/Add-in example docs - https://learn.microsoft.com/en-us/graph/tutorials/office-addin.
All is working well when the add-in runs in Excel (making sure the add-in can run in Excel and using an Excel manifest) and the call to OfficeRuntime.auth.getAccessToken returns the api token.
If I run the add-in in Outlook (after changing the add-in to run in Outlook and using an Outlook manifest) I get an error:
getAccessToken error: {"name":"Error occurred in the authentication
request from Office.","message":"An unexpected error occurred in the
client.","code":13006}
With Outlook I notice that two calls are made that aren't with Excel.
(1) https://outlook.office.com/owa/service.svc?action=GetAuthenticationUrl&app=Mail&n=104
Response:
ResultCode 0
WebSessionType 0
AuthenticationUrl
"https://ccs.login.microsoftonline.com/ccs/common/oauth2/authorize?client_id=00000002-0000-0ff1-ce00-000000000000&redirect_uri=https%3a%2f%2foutlook.office.com%2fowa%2f&resource=00000002-0000-0ff1-ce00-000000000000&response_mode=form_post&response_type=code+id_token&scope=openid&msafed=1&msaredir=1&client-request-id=c75b3cd3-db77-0845-413d-d1890fe17698&protectedtoken=true&tokenenvelope=true&claims=%7b%22id_token%22%3a%7b%22xms_cc%22%3a%7b%22values%22%3a%5b%22CP1%22%5d%7d%7d%7d&nonce=637823342196948067.4c7773c4-3cd6-4e00-8bd9-ccd655dda53e&state=FcfBDYAwCEBR1DgOBguFdgH3qNCbN_dPxMNP3l8AYMvWbKFf-zWedybAlK0VZiln1y6N1A5xM2MXZA9FmUTY7ujoubVGjMrzAw"
ImplicitGrantAuthorizationUrl ""
(2) https://ccs.login.microsoftonline.com/common/oauth2/authorize?...
Response:
404 Not Found
I don't know why Excel and Outlook are behaving differently except maybe because of the manifest setup.
For Excel there is this:
<VersionOverrides xmlns="http://schemas.microsoft.com/office/taskpaneappversionoverrides" xsi:type="VersionOverridesV1_0">
....
<WebApplicationInfo>
<Id>123</Id>
<Resource>api://localhost:3000/123</Resource>
<Scopes>
<Scope>openid</Scope>
<Scope>profile</Scope>
<Scope>access_as_user</Scope>
</Scopes>
</WebApplicationInfo>
....
For Outlook there is this:
<VersionOverrides xmlns="http://schemas.microsoft.com/office/mailappversionoverrides" xsi:type="VersionOverridesV1_0">
<VersionOverrides xmlns="http://schemas.microsoft.com/office/mailappversionoverrides/1.1" xsi:type="VersionOverridesV1_1">
....
<WebApplicationInfo>
<Id>123</Id>
<Resource>api://localhost:3000/123</Resource>
<Scopes>
<Scope>openid</Scope>
<Scope>profile</Scope>
<Scope>access_as_user</Scope>
</Scopes>
</WebApplicationInfo>
....
To use SSO with an Outlook add-in, you must enable Modern Authentication for the Microsoft 365 tenancy. For information about how to do this, see Exchange Online: How to enable your tenant for modern authentication.
To use SSO, your Outlook add-in will need to have a server-side web API that is registered with Azure Active Directory (AAD) v2.0. For more information, see Register an Office Add-in that uses SSO with the Azure AD v2.0 endpoint.
Note, a new Single Sign-on (SSO) service will replace the existing one for Office Add-ins that are used in Office on the web. This new service is aimed at providing better reliability and supporting additional environments where Office on the web is used. This only applies to add-ins for Word, Excel, and PowerPoint. Outlook Add-ins are not impacted by this new service roll out. Read more about that in the New Single Sign-on service for Office Add-ins rolling out in Office on the web article.
Finally, I'd suggest creating a new add-in for Outlook from scratch and check whether it works as expected.
I am trying to publish a very simple workflow from SharePoint Designer 2013 to SharePoint Online.
The following error appears:
Microsoft.SharePoint.SPPrincipalManagementException: An error occurred
while attempting to execute a principal management operation. Please
contact your administrator. --->
System.ServiceModel.FaultException`1[Microsoft.Online.Administration.WebService.PropertyValidationException]:
Invalid property specified
Server stack trace: at
System.ServiceModel.Channels.ServiceChannel.HandleReply(ProxyOperationRuntime
operation, ProxyRpc& rpc) at
System.ServiceModel.Channels.ServiceChannel.Cal
How can I handle this?
You can try create a new sub-site from your site collect then upload your workflow to see if its viable.
If not, you can check whether the Central Admin > Manage Service Application-> “App Management Service” is started.
Also heck whether the “Configure service application associations”, ”App Management Service” is already associated.
Then check whether the “Manage Services on server” and the “App Management Service” is started.
In addition, try to re-register Workflow Service.
If the issues still exists, please follow the steps in the Steps to Verify that Server Is Correctly Set Up. After you verified that the server is correctly set up, follow the steps in the Steps to Troubleshoot Workflow Management Service and Troubleshooting the Service Bus for Windows Server then retry your action.
If all above doesn't solve problem, then you should create a service request to Microsoft in SharePoint Online Admin Portal directly. Since issue is more likely related to SharePoint Online Server Back end.
Say SORRY at first that I really don't know how to submit feedback to Microsoft.
I had tried every edition of SharePoint and SQL Server. Which the new released SharePoint Server 2016 occur the error below again and again when running Configuration Wizard:
An error occurred while getting information about the user sp_admin at server hub.com: access denied
Other edition likes SharePoint Server 2013 and (SQL Server 2012 SP3 or 2014 SP1) works fine with same configuration.
So two questions,
How to do feedback?
How to resolved this bug?
Make sure you are running the setup with the setup user account (spAdmin) and configured its necessary security roles for the sql server:
securityadmin (fixed server role)
dbcreator (fixed server role)
See this reference for details about suggested domain accounts and their security roles.
Trying to figure out SSO.
We installed ADFS on our Windows Server 2012 then I created an Azure Active Directory version of an SSO sample project following:
https://github.com/Azure-Samples/active-directory-dotnet-native-client
That worked fine.
Then trying to port it to our Windows Server 2012 ADFS I followed this tutorial:
http://www.cloudidentity.com/blog/2013/10/25/securing-a-web-api-with-adfs-on-ws2012-r2-got-even-easier/
Which at one point says to run the following powershell command to add the WPF windows client to ADFS:
Add-ADFSClient -Name “MyClient” -ClientId “E1CF1107-FF90-4228-93BF-26052DD2C714” -RedirectUri “http://anarbitraryreturnuri/”
But this tutorial is geared towards Windows Server 2012 R2 and we run the plain Windows Server 2012 version and this Add-ADFSClient powershell command is missing.
How can I do the equivalent adding of a Windows client to ADFS on Windows Server 2012?
Thanks!
The samples and commands you are running are OAuth and there is no OAuth support in 2012 hence the lack of the PowerShell command.
2012 R2 supports OAuth authorization code grant only.
2016 (TP3) has the full OpenID Connect / OAuth stack.
This will be a simple answer for those used to Windows authentication but as Solaris Sysadmin I am just looking for some clarification on how to implement Windows Authentication between an application running on an IIS7 Web Site (running on Server 2008 R2) and a Microsoft SQL 2008 Server.
The application at the moment uses this tag:
Data Source=mydbserverhostname;Initial Catalog=TheDBName;User ID=testuser; Password=apassword
In the specifications it is supposed to use this:
Data Source=mydbserverhostname;Initial Catalog=TheDBName;Integrated Security=SSPI;
I would like to go back and get the Windows Authentication working before I have to deploy to Production. From my understanding of Windows I need to have a Windows Domain account to authenticate against a Service Account which has been set on the SQL Server 2008.
What I am missing is how to achieve this and how to get it running as a service so that I can log out and leave IIS7 running the site and the SQL Server talking to each other.
I have read a couple of similar questions on this forum but the answers seem to be "just switch to SQL Authentication" which I need to avoid in the final implementation.
Any help would be appreciated.
When using the DefaultAppPool change the Identity to a custom username and password that matches the service account that has been created on the SQL Server/(LDAP) as per:
http://www.iis.net/learn/manage/configuring-security/application-pool-identities