Apologies for the basic question; we're having a spring clean of the office Active Directory and plan to remove a large number of legacy users. Saying good-bye to their email is not a problem, but we have an on-premise Dynamics CRM we occasionally refer to. My question is, will there be any implications for that if I delete a user who might have entered a case?
There is no direct link between CRM on-premise 2011 & Active Directory to pull all users overnight & sync. When you create a new user in CRM by giving domain name, it will verify in AD & pull the details to store in CRM. This will happen on tab out.
So when you delete/disable an AD user it won't flow down in Dynamics. But you have to disable them manually (no delete option available). Before doing that make sure to read these best practices.
Best Practices
Make sure to Re-assign any associated records/activities to another
User or Team before disabling User. If you don’t Re-assign the records
they will still be available, but they will still be assigned to the
disabled user.
It is very important to ensure that there are no Workflows owned by
the User to be disabled. All Published Workflows need to be owned by
an administrative account, not an employee’s account.
There are situations where a User’s account only needs to be disabled
for a short period of time, so records don’t necessarily need to be
Re-assigned. (Example: the User went on vacation for a month). Take
into consideration the User’s privileges for those records. If only
the User can modify that record, then no one will be able to modify
the record, if the owner is disabled.
Read this community thread as well.
Related
Is there any possibility to create sub-users under a user account using one license, but taking into account they need to have full access to the main functionalities of the CRM.
No. Even by sharing a user between multiple people you would likely be breaching your licence terms.
Without understanding why you would want to do this, if the reason is cost, I would suggest investigating Power Apps and Team Member licences. They are a cheap way to access Dynamics data, although can be restrictive.
I would need to restrict the deletion of a record for system administrator without using any custom code (like javascript, plugin). Can someone please suggest me the possible approaches for this.
I assume you just want to restrict deleting with no condition to check. There seems no logic in this scenario, why would anybody need this to be implemented that too for System Administrator.
Well if it is your ultimate goal then this could be done with below steps,
Create Workflow on delete trigger.
Create step as "Stop Workflow"
Set Status as "Canceled"
Save and Activate the workflow
You can set the custom Message in step parameter "Status Message". This will be visible while deleting a record.
You can't change the system administrator role out of the box. I would suggest the following approach:
Copy the System Administrator role (e.g. System Manager), but remove delete permissions.
Give users your copied System Manager role.
Remove System Administrator role from all but 1 user.
I'm pretty sure there has to be at least 1 account with system administrator role, but at least this way you can restrict delete permissions.
Seriously the problem is not the delete privilege in System Admin role. It’s the problem with system implementation, and power users who don’t know the real power they possess. First of all, System Admin/Customizer should not be given to end users.
Solution is design another Tool admin role(like James said), Assign it & educate the users. Taking out data governance from tool users & keeping it with Dev team is not a good move. If you have Prod support team, then fine.
Learn what different user base needs in day-to-day work, design well like considering user level privileges (they can delete what they create, etc), make use of Dynamics 365 CRM powerful security concepts, approval or layered process with Tool admins or Prod support, even dashboards for junior users, senior users, Audit reports, identifying tool champions for user training & revisiting the security gaps are key steps here.
Also only Read, Append, AppendTo should be given for Master entities (country, state for example), sometimes user will edit/delete the actual data instead of lookup value.
I bought CloudBerry Ultimate software (Link for more information) to make backups. On that software I can control when the software deletes the objects I backed up, but I want to be sure that will be impossible to delete files from my Google Storage Nearline, I know that Amazon Web Services have the Amazon Glacier with VaultLock that prevents to delete objects for a period of time and is impossible to delete (even if you have all administrative privileges) any object or modify the parameters.
Does any one know how can I prevent to delete any object from my Google Nearline account?
It's not possible. There's no such thing similar to Glacier Vault Lock. You can temporary suspend a user though.
You can temporarily block a user's access to your organization's
Google services by suspending their account. This doesn't delete their
email, documents, calendars, or other data. And their shared documents
remain accessible to collaborators. But the user can no longer sign in
to their account. Also, new email and calendar invitations are
blocked. After suspending a user, you can restore the account at any
time.
https://support.google.com/a/answer/33312
I can't find much about this online so I was wondering if someone knew here.
Is SSRS 2005 if a user creates a subscription, will other users be able to view and edit those subsciptions? If not, is it possible to make subsciriptions visible to everyone?
Thanks
Quick answer is no.
Long answer is:
AFAIK, there is no site-wide subscription management functionality. The best you can do within Report Manager is site-wide schedule management, which allows admins to set up schedules at preferred times and let users choose those schedules when creating their subscriptions.
Our solution for controlling/centralising subscriptions was to set up a generic Windows user, log in to Report Manager and use that user to create all subscriptions. This means that all requests for subscriptions go through the IT department (+ or - depends on your situation. We didn't want users creating subscriptions themselves). All users who know the generic username/password can manage subscriptions in one place. Not ideal but it works for us.
Another option is that all the data for subscriptions is held on the Server, either in the Reporting Services database or in the Jobs themselves. If you are brave you can delve in and set up some sort of interface to access this.
This is definitely an area in which I find SSRS lacking.
Update:
You live and learn. I've just found that (provided you have sufficient privileges) if you open a report, then go to the subscriptions tab, you can view and edit any subscriptions that are set up on this report by any user. Still not ideal as you don't get an overview of the subscriptions across the system but better than the bleak picture I painted previously!
Do you know of a way to get rid of CRM User accounts in MSCRM 4.0? After some user accounts have been deleted in AD we're faced a lot of issues while importing the organisation to another server stating that there are issues with the user mapping.
What kind of idea is behind the fact that no user accounts can be deleted from the crm installation? Is there any tool or undocumented Webservice API call to get rid of crm users?
Thanks for sharing yours insights
There is no working way of actually removing CRM users from the database; I think one reason is that it would cause all the records previously owned by a now deleted user having no owner at all (the same goes for the createdby and modifiedby fields), which would put the database in an illegal state.
The official way of removing a user from the CRM system is deactivating the systemuser record. This does not sever the connection to the AD user, however, but I think deactivated users should not cause problems when reimporting the organization; I'm not sure of that, though.
You could theoretically delete the systemuser records from the database using SQL, but that's highly unadvisable.
Changes in the AD users are actually causing various issues with MSCRM quite often; a larger customer even had us develop a solution for automatically synchronizing their CRM users with the state of the AD because managing that manually proved to be too much work in a large environment with a few hundred users.