This is Dynamics CRM 2011 Rollup 11 On-Premises with SQL 2008 R2
Have the following scenario that we're trying to debug:
In a Synchronous PostCreate plugin we add users to a Team that owns a specific record and has read permission on that record via a security role. That should mean that when the Create process is completed the users added to the Team have access to the record. When such a user then goes to open the record they get a SecurityException ReadAccess error. The record does show in grids, which should not happen if they do not have Read permission on the record.
As a further test we execute the SDK call RetrievePrincipalAccessRequest for the user and record, from a console application, and see that the user does not have Read permission.
We can look a the Team Member list in the UI and user is a member of the Team. If we wait long enough (and create another record the issue will eventually resolve itself - several minutes later.)
We can add a user to the team, using the same code we executed in our Plugin (but running in a console app), and the user has Read permissions and can access the record immediately after the call completes.
There is clearly something going on in our Plugin that is causing an issue but we cannot figure out what or why - since the Create call completes without error and we can see the user listed in the UI. We are not doing anything funky - i.e., direct SQL, external service, etc.
We call a standard CRM 2011 SDK message and it completes without throwing an error. We can validate that the user was added in the user interface. The user have permission to Read the entity but they do not.
Any thoughts/ideas?? We've been tracking like crazy but haven't found our smoking gun!
UPDATE
We can reduce the incidence if you we put a pause in our plug-in code. This error only occurs when the add is done during a plug-in, not when it is done outside the plug-in. I'm starting to wonder if there is a SQL procedure/statement (there are three stored procs that fire when a user is added to a team) that gets cut short or fails to complete, for one reason or another, since the add is successful when not done in plug-in code.
Finally found the answer in the list of items resolved by Rollup 18 (http://support.microsoft.com/kb/2958724)
If You are assigning Team Membership via plugin, the user Cache does
not get invalidated, causing an error when trying to retrieve a
record. The issue occurs if the Team is has a security role and Access
Rights are controlled via Team ownership.
We had opened a ticket about 2 months ago with Microsoft which had involved a lot of back-and-forth but not a definitive fix.
So if you experience the same issue on CRM 2011 you need to update to Rollup 18.
Related
I look for a way to collect and save activity and security logs from the Azure devops server(onprem 2019.1).
Logs include - user logins, build events, work item events, security changes etc.
I'm aware about this option https://server_name/tfs/_oi/_diagnostics/activityLog. But it's not an api interface.
Any Idea how it's can be implemented that?
Thanks.
TFS keeps track of an activity log of all recent activities. This information is stored in 2 tables inside Tfs_Configuration and Tfs_collectionname called tbl_Command and tbl_Parameter. These tables keep a record of every single command that every single user has executed against TFS for the last 14 days.
If you don’t want to get activity log through tbl_Command table and hidden activity log page (http://server:port/tfs/_oi), I’m afraid there is no other way at present.
You could add your request for this feature on our UserVoice site, which is our main forum for product suggestions. After suggest raised, you can vote and add your comments for this feedback. The product team would provide the updates if they view it.
We created an application with SCIM support over two year ago now and it always worked fine. However recently we have been getting reports from customers that users were no longer deleted/disabled from the target enterprise application.
I already saw there was another question like this one a few years back but that seems resolved and this seems like another issue.
We did a little research on our own and noticed that azure is not sending any requests at all when we remove a user from the assigned user list. We checked the incoming logs from our application and IIS logging and both do not show any requests are sent our way. (we do get logs from POST/GET/PUT of other provisioning related tasks, like creating a user).
In azure audit logs we do see the following:
Remove app role assignment from user
Add a deletion-marked app role assignment grant to user as part of link removal
Which seems to me that azure is doing something, it's just not sending it to the targeted application
Current situation:
We have user A that was created in azure ad and is assigned to our application. Provisioning configuration was done by means of SCIM in azure. And the user is also created in our application, so the connection seems fine.
When I remove the user from the assigned user list in our enterprise application, I expected that counts as a softdelete, causing Azure to sent a PATCH or a PUT to set the active property of the user to false. In case I would delete them entirely from AD I expected them to be removed with the DELETE. I read that it takes up to 30 days which is no problem, but the problem is that user that are no longer assigned are still active in the target application, which is no good.
I have some basic properties mapped on the user and the one thing that might be involved with this issue would be the Not([IsSoftDeleted]) mapping which is mapped to our active property. I don't see how that is wrong, but that's all I can think of at this point.
Anyone that can has any idea what is going here?
Thanks!
I have had contact with Microsoft regarding this issue and it seems to be a bug on their end which they are currently correcting. It is part of a larger set of bugfixes all regarding similar issues so they could not give me a specific time when this specific issue was resolved, but they think around the 10th of July (2020).
In any case, as this was a bug due to changes pushed by MS this is no longer an issue to be solved.
Update:
I have received some replies that a few bugs were fixed connected to this issue but not all. I'm currently on vacation so i'm not sure if the main issue is fixed as well. They did promise a fix fast though.
For now all I can give you is a workaround. The issue happens when the only change that is happening is the unassignment of users, it simple won't execute this until at least 1 property from an assigned user is also changed. When anything is changed, it will fix all unassignments and disable them all, even if the unassignment was in a different sync cycle. So until the actual fix is pushed, that might be helpful to know.
I will keep this thread updated if I get more information.
Ps: The Azure team requested that if anyone else also ran into this issue they report it through Azure. Their dev team will see if your problem matches up with my issue or if it's something new. So please do that as well.
I have a Plugin on the Creation, Updating, and Deletion of the OpportunityProduct entity in the CRM 2011. I want to through exception on the success of some operations, means want to display dialog. It is working fine for Update and Delete. But it is not working fine for the Creation of OpportunityProduct, it is not throwing exception in the dialog. It is showing Exception: “An error has occurred, Try this action again. If the problem continues, check the Microsoft Dynamics CRM Community for solution or contact your organization’s Microsoft Dynamics CRM Administrator. Finally, you can contact Microsoft Support.”
Message : Create
Primary Entity : opportunityproduct
Action: Pre-Operation
Execution Mode: Synchronous
I think this is an internal issue that relates to how CRM treats compound entities such as opportunity product.
To verify this behavior you should put breakpoint in your code and inspect the context depth and parent context to understand if the create event is indeed a child process or the opportunity.
If so you might be able to re-register the plug-in the opportunity and try to somehow throw the error from there.
I have a custom entity related to Account.
When I create a record of the custom entity from the Account an error message is shown:
Error
An error has occurred....
If this continues, contact your system administrator.
There is no problem creating the record from the entity itself.
There is a JavaScript function registered on-save of the custom entity that prevents the save if the record is a duplicate.
Why does the create/update not work from the related Account?
Although I agree with #PedroAzevedo's idea to turn tracing on, I disagree with his method because the CRM Diagnostic tool is a lot easier: http://crmdiagtool2011.codeplex.com
I'd also check for a plugin registered on the update of the Account Entity. It may be failing there, which would account for why it does work on the entity form itself...
Active the trace and see full error description. Another thing you can check is the security role, if you have permissions for the action AppendTo at Account.
The problems is IE 10. I installed Windows 8 last night and do not yet have update rollup 12 installed.
The same error occurs when I try to add a contact to the Account.
We are using an infopath form that when submitted is supposed to fire off a custom .NET workflow. Basically, the information within the form is used to create a new sharepoint site. What I am seeing happen is that the first time the workflow runs (which is automatic after the form is submitted), the workflow errors out. When I run the workflow manually immediately after it fails, the workflow runs fine.
this.workflowProperties.Item["Client Name"]
I've debugged the issue down to the above line where workflowProperties is of type Microsoft.SharePoint.Workflow.SPWorkflowActivationProperties. The first time the workflow runs, the property listed above (and all others) are null. The second time it is run the client name property is as it should be (populated from the infopath form).
Another important piece of information is that this workflow was working fine for over a year and suddenly started not working correctly a few weeks ago for no particular reason. We were having some permissions issues the past month but I cannot see how that could be related to the workflow issue. The user I am logged in as is a site collection administrator. I use the same user to kick the workflow off manually (which succeeds). I do not think that the workflow runs as the user that is logged in though (when it is run automatically on form submission).
Another interesting wrinkle to the whole situation: there are a total of 3 custom workflows that the application uses. 2 were made in visual studio - one of these works fine and other is displaying the behavior described above. The last was made in sharepoint designer and is failing.
I'm willing to try just about anything at this point. I am on a dev server (which displays the exact symptoms as production) so I can try just about anything.
I'm guessing this has to do with the workflow being fired asynchronously from the commit operation that sets the fields values. Can you try and fetch the item explictly from the list instead of using the Item from the workflow properties. something like the following:
SPListItem l_item =
workflowProperties.Item.List.Items.GetItemById(
workflowProperties.Item.Id
);
i'm not certain, but it may be worth a try.
The other thing to keep in mind is the SPContext.Current object will be null if being called from an EventReceiver, but will be valid if called manually. It doesn't sound like this is the issue, but its something to be aware of nonetheless.
If the InfoPath forms are submitted from a Vista or Win 7 machine, you might face this issue of getting a NULL value for the fields in the InfoPath form. Try adding a delay activity with around 10seconds and see if your are able to get the value of the fields from InfoPath.
Refer to this link for more details: Why does my SharePoint workflow fail when the client is running Vista or Windows 7?
Try looking in your SharePoint Logs.
They are located under the 12-Hive in the LOGS folder - open up the latest and look for something with 'Workflow infrastructure' in it, maybe that can point you in the right direction.
The "solution" was to do an export and transfer to a new server. Basically just use STSADM to do the export operation and then import the same file on the new server.
SEE:
http://sharepointdogs.wordpress.com/2008/07/30/content-migration-or-backuprestore-in-moss-2007/
I was on the phone with Microsoft Support for hours on this issue - transferring to a new server would be my recommendation for anyone else that might encounter this problem.