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.
Related
I'm getting an error when I try to create a pipeline in our Azure DevOps. I've created a service connection for Azure US Gov to Azure Resource Manager that seems to have verified and saved successfully. Tried different browsers / incognito mode with no luck.
Error Message...
"You don’t appear to have an active Azure subscription."
Running version 18.181.31626.1 (Azure DevOps Server 2020 Update 1.1)
I've configured the service principal with contributor access. The connection appears to verify okay in DevOps when creating the service connection. In this example I'm selecting the option for Docker, though it appears to replicate against any of the options in the list. When selecting any of the options I see the pop out window on the side state "You don’t appear to have an active Azure subscription."
Please follow these steps to troubleshoot the error "You don’t appear to have an active Azure subscription".
1.Go to https://ms.portal.azure.com/#blade/Microsoft_Azure_Billing/SubscriptionsBlade to check if your subscription status is active.
2.Go to https://ms.portal.azure.com/#blade/Microsoft_AAD_IAM/TenantPropertiesBlade to check whether the Security defaults is disabled.
Note
Remember to switch to your subscription aad in the steps above.
In addition, when the user is assigned the subscription (access level above contributor) for the first time, it needs time to sync the changes when logging in to Azure DevOps.
We're experiencing issues with a third-party application running on Windows 2016 that uses Kerberos and SSPI (Windows Security Support Provider interface) where the vendor has suggested this could be related to Kerberos authentication failures. The service runs as a domain service account. In the Windows 2016 domain controller security logs we're seeing Event ID 5071 failure audits with the description:
Key access denied by Microsoft key distribution service
This all worked in the past and similar configuration works in other parts of our system (different service accounts, servers, domain controllers). In fact, we have a full hardware level clone of our setup as a test system and the issue doesn't exist there.
There is limited information online that we've been able to find on this particular event. We are in the process of performing all the normal Kerberos advanced troubleshooting so don't need assistance from that angle. We have a ticket open with Microsoft so will post their response here.
Has anyone encountered this event previously and has any insight into the potential cause(s)?
I am creating a logic app that will trigger when a form request is submitted.
The MS Form connector requires me to sign in. This is acceptable during development, but we have a lot of logic apps and so use DevOps to automate deployment.
With the current connector, after deployment we still have to:
manually open the logic app in the portal.
connect using authorized credentials.
save the logic app.
This manual process completely defeats the point of using DevOps with Logic Apps.
Its a similar issue when using the Outlook connector.
Is there a way to supply server principal credentials to these connectors, so that they are correct at deployment time and require no manual intervention?
It seems that it's not supported to login on MS Forms connector with service principal. Connectors that can use service principal authentication will have "Connect with Service Principal" option, like Azure Data explorer. You can give your voice on this feedback to promote this feature.
API Connections with OAuth authentication, like Office 365 and Microsoft Team connectors etc, require manual consent. Unfortunately, at this point in time, authentication for those cannot be fully automated.
Here is a ticket you can refer to.
The developer who installed my Azure devops Git environment left a few months ago. My new developer doesn't really understand this environment.
We were using it already for several weeks, but yesterday I received an error message:
If I understood what my ex developer said, is that he placed an Agent in me remote desktop connected to my server which I have to activate (run as administrator) in order to deploy the Azure devOps releases.
But this time there is a "getaddrinfo ENOTFOUND" error which I don't understand an my new developer neither.
To narrow down the issue, please follow the items below:
Set variable system.debug to True in your pipeline, and click the error in your screenshot to check the detailed error log.
Go to the FTP service connection you are using in your pipeline, update the username and password, or create a new service connection to make sure your FTP server is connected.
I am using Oracle adapter from the BizTalk Adapter Pack (WCF based for BTS 2006 R2). In the configuration of the "solicit-response" send ports, I have used Oracle's username and password to connect to the database.
Now I would like to change that and use the SSO. So far I have created the Affiliate application and mapped the BTS Host Instance "user id" to the Oracle database user details.
When I run the application I am constantly getting the error: "Unable to redeem ticket, no ticket exists in the message".
reading through the BTS documentation I found the following at "ms-help://MS.BTS.2006/BTS06CoreDocs/html/c7bf755c-c37d-4b19-9817-a7f42e1e9656.htm":
In scenarios where an orchestration invokes the send adapter, the BizTalk Messaging Engine sends the message to the MessageBox database. The orchestration should ensure that both the SSOTicket context property and the Microsoft.BizTalk.XLANGs.BTXEngine.OriginatorSID context property of the message that contains the ticket are maintained. When the adapter receives this message from the MessageBox database, the adapter calls the RedeemTicket method with the encrypted ticket to retrieve the back-end credentials from the SSO store. The user designing the orchestration should specifically copy this property to the message.
But I receive a message through SQL integrated connection, that doesn't have the SSO Ticket.
Please help to resolve this issue?
You can add an SSO ticket in a custom pipeline component on the send port. The following code works for me:
public IBaseMessage Execute(IPipelineContext pContext, IBaseMessage pInMsg)
{
ISSOTicket ssoTicket = new ISSOTicket();
pInMsg.Context.Write("SSOTicket", "http://schemas.microsoft.com/BizTalk/2003/system-properties", ssoTicket.IssueTicket(0));
return pInMsg;
}
This will generate a ticket for the Biztalk host instance service account, so your Oracle affiliate application mapping should work as you expect.
You might need to "Allow tickets" to the System properties in SSO Administrator. Without that it will not work even if you allow tickets to the Affiliate Application.