Je suis parfaitement conscient que la suppression des utilisateurs (entité SystemUser) dans CRM Dynamics 2011 n'est pas prise en charge par Microsoft.
Cependant, nous développons actuellement un outil pour répondre aux besoins de notre provisionnement des utilisateurs. Afin de pouvoir rédiger des tests d'intégration pour cet outil, il semble nécessaire de pouvoir supprimer les utilisateurs par la suite, afin que nous puissions annuler notre environnement de test à l'état d'origine.
Actuellement, nous le faisons en restaurant des organisations de sauvegardes SQL, mais cela prend trop de temps à faire pour chaque essai.
Jusqu'à présent, la meilleure solution que nous avons est de créer un utilisateur dans le test d'intégration, affirmant tout ce que nous devons affirmer, puis "nettoyer-le" en désactivant l'utilisateur et en supprimant ses informations d'identification publicitaires, de sorte que nous puissions re -Utilisez ces informations d'identification pour la prochaine analyse du test.
Cependant, comme nous recherchons uniquement une solution pour un environnement de test, j'aimerais vraiment avoir une solution qui nettoie tout correctement: la suppression des enregistrements en SQL semble être la voie à suivre. En raison de la structure de DB complexe, toutefois, j'espérais que quelqu'un pourrait fournir des scripts pour cela.
Nous avons créé le script pour supprimer manuellement l'utilisateur de SQL (voir réponse acceptée). Ceci est non pris en charge , alors utilisez-le uniquement dans des environnements de test, si vous savez ce que vous faites.
6 Réponses :
Ce n'est pas pris en charge, mais que diriez-vous de supprimer les enregistrements directement à partir de SQL?
jamais essayé moi-même et je ne voudrais pas le faire sur un environnement de production, mais si c'est juste pour tester / développer, le pire qui se produit, c'est que vous déduisez un environnement de développement.
En effet, j'ai déjà pensé que cela pourrait être le moyen le plus simple de le faire. Toutefois: J'espère que quelqu'un l'a déjà fait et peut fournir le script SQL pour le faire, car ce sera complexe.
Peut-être que vous pouvez essayer ce travail autour. Plutôt que de simplement les désactiver, modifiez le nom Active Directory sur autre chose, puis désactivez les enregistrements.
Par exemple, votre script pourrait être comme suit (en supposant l'authentification AD):
Créer des utilisateurs de la publicité msmith , bmiller , et jdoe .
Effectuez des tests et une validation.
mise à jour
msmith à testutilisateur1
Mise à jourBMiller testuser2
Mise à jourjdoe à testuser3 désactiver testuser1 , testuser2 , testuser3
Le prochain test devra utiliser Testuser4 , Testuser5 , Testuser6 , ce qui signifie que vous devez créer de nombreux comptes factices, Mais il peut être plus facile de le faire, que de gâcher avec la base de données CRM SQL.
Pour mes tests de l'unité où j'ai besoin d'un utilisateur, je me moque de l'appel IorganizationVice pour juste des demandes SystemUser et renvoyez une entité SYSTEMUSER SYSTEMUS SANS SANS IT FLASE. Je suggérerais cela aussi, mais on dirait que vous essayez de tester la création d'utilisateurs du système, ce n'est probablement probablement pas une option dans ce cas.
Merci beaucoup pour votre réponse. Votre travail autour semble vraiment réalisable. Cependant, il nous obligera à garder un compteur de combien d'utilisateurs que nous avons déjà créés et que notre environnement de test d'intégration CRM est vraiment encombré de vieux utilisateurs de test. Tellement une option, mais pas idéal, je penserais.
S'agissant de l'utilisateur: cette approche n'est en effet pas une option pour cette demande spécifique, comme nous l'aimerions tester la création d'un système SystemUser.
@Jorisvanregemortel - Vous n'avez pas besoin de conserver un compte de combien d'utilisateurs que vous avez déjà créés, vous pouvez simplement faire une requête et rechercher le plus grand testauser (peut souhaiter nommer Testuffer00001 à des fins de tri). Mais encore une fois, cela pourrait être un cas de remède étant pire que la maladie (c'est-à-dire qu'il serait plus facile de déterminer le SQL requis pour nettoyer les comptes d'utilisateurs, que créer tous ces comptes d'utilisateurs)
D'accord sur la requête pour le nombre d'utilisateurs Max, ce sera le moyen le plus simple. Cependant, cela laisse encore l'environnement d'essai d'intégration encombré. Un SQL Supprimer sonne toujours comme une meilleure option - bien que cela ne soit pas pris en charge. Merci beaucoup pour vos réponses jusqu'à présent, cependant!
Vous pouvez utiliser le moyen totalement non pris en charge de les supprimer par SQL.
Tant que vous le faites dans un environnement d'essai d'intégration, je pense que le préjudice serait relativement faible.
Pour trouver les modifications apportées dans la base de données lors de l'ajout d'un utilisateur que vous pourriez
Cela pourrait être ces changements avec chaque rouleau alors veillez à ne pas compter sur ceci pour quelque chose de code critique ou de production.
J'étais arrivé à la même conclusion. Cependant, je ne peux pas croire que personne n'a fait cela auparavant. Je vais lui donner un peu plus de temps avant que je vais moi-même créer le SQL moi-même :)
Le script suivant n'est pas pris en charge par Microsoft. L'utilisation de cela peut nuire, brique, exploser ou molester votre organisation CRM, déploiement, serveur et votre carrière. Cela étant dit, nous avons utilisé cela, et cela a fonctionné bien pour notre objectif: nettoyer notre environnement de test après avoir exécuté Autres choses à garder à l'esprit:
N'utilisez jamais ça.
Jamais. addsystemuser tests.
Je devais ajouter deux lignes à votre script. Merci beaucoup BTW! Supprimer de dbo.UserQueryBase où propriétaire = \ @userid Suppr de DBO.SystemuserProfiles où Systemuserid = \ @userid
Voici ce que j'ai fait dans CRM 2015 basé sur le code Joris une fois que vous avez exécuté la requête et que vous avez assuré qu'il supprimait les bonnes données, vous pouvez non-commenter le commit Déclaration et commentaire L'instruction Rollback espérons que cela aide.
juste quelques légères modifications pour Dynamics CRM 2016 (sur Principe) pour permettre des erreurs de contrainte courantes que j'ai rencontrées. Encore une fois, cela est totalement non pris en charge et procéder à vos risques et périls. (Je vais mettre à jour lorsque je trouve d'autres erreurs de contrainte.)
BEGIN TRANSACTION DECLARE @username AS VARCHAR(50) /* CHANGE THIS LINE ONLY */ SET @username = 'DOMAIN\USERNAME' /* END CHANGES */ DECLARE @userId AS UNIQUEIDENTIFIER SET @userId = (SELECT SystemUserId FROM dbo.SystemUserBase WHERE DomainName = @username) DECLARE @orgid AS UNIQUEIDENTIFIER SET @orgid = (SELECT OrganizationId FROM dbo.SystemUserBase WHERE systemuserid = @userid) DECLARE @userEmail AS VARCHAR(MAX) SET @useremail = (SELECT InternalEMailAddress FROM dbo.SystemUserBase WHERE SystemUserId = @userid) DECLARE @userfullname AS VARCHAR(max) SET @userfullname = (SELECT fullname FROM dbo.systemuserbase WHERE systemuserid = @userid) DECLARE @queueid AS UNIQUEIDENTIFIER SET @queueid = (SELECT queueid FROM dbo.SystemUserBase WHERE SystemUserId = @userid) DECLARE @ownerid AS UNIQUEIDENTIFIER SET @ownerid = (SELECT ownerid FROM dbo.OwnerBase WHERE name = @userfullname) DECLARE @MSCRMUserID as UNIQUEIDENTIFIER SET @MSCRMUserID = (SELECT Userid FROM mscrm_config..SystemUserOrganizations WHERE CrmUserId = @userid AND OrganizationId = @orgid) DECLARE @authinfo as NVARCHAR(255) SET @authinfo = (SELECT Authinfo FROM mscrm_config..SystemUserAuthentication WHERE Userid = @MSCRMUserID) DECLARE @SUid as UNIQUEIDENTIFIER SET @Suid = (SELECT id FROM mscrm_config..SystemUserAuthentication WHERE Userid = @MSCRMUserID) DELETE FROM dbo.UserSettingsBase WHERE SystemUserId = @userId DELETE FROM dbo.TeamMembership WHERE SystemUserId = @userId DELETE FROM dbo.SystemUserPrincipals WHERE SystemUserId = @userId DELETE FROM dbo.SystemUserRoles WHERE SystemUserId = @userId DELETE FROM dbo.SystemUserBusinessUnitEntityMap WHERE systemuserid = @userid DELETE FROM dbo.UserQueryBase WHERE OwnerId = @userid DELETE FROM dbo.SystemUserProfiles WHERE SystemUserId = @userId DELETE FROM dbo.TeamMembership WHERE SystemUserId = @userId DELETE FROM dbo.QueueMembership WHERE SystemUserId = @userId update dbo.SdkMessageFilterBase set ModifiedOnBehalfBy = NULL where ModifiedOnBehalfBy = @userid update dbo.SdkMessageFilterBase set CreatedOnBehalfBy = NULL where CreatedOnBehalfBy = @userid DELETE FROM dbo.SystemUserBase WHERE SystemUserId = @userid DELETE FROM dbo.CalendarRuleBase WHERE CalendarId IN (SELECT CalendarId FROM dbo.CalendarBase WHERE PrimaryUserId = @userid) DELETE FROM dbo.CalendarBase WHERE primaryuserid = @userId DELETE FROM dbo.QueueBase WHERE QueueId = @queueid DELETE FROM dbo.PrincipalEntityMap WHERE PrincipalId = @ownerid DELETE FROM dbo.PrincipalObjectAccess WHERE PrincipalId = @ownerid DELETE FROM dbo.UserEntityUISettingsBase WHERE OwnerID = @userid DELETE FROM dbo.UserApplicationMetadataBase WHERE OwnerID = @userid DELETE FROM dbo.PostFollowBase WHERE OwnerID = @userid DELETE FROM dbo.MailboxBase WHERE OwnerId = @ownerid DELETE FROM dbo.OwnerBase WHERE OwnerId = @ownerid DELETE FROM dbo.EmailSearchBase WHERE EmailAddress = @userEmail DELETE FROM dbo.ResourceBase WHERE name = @userfullname DELETE FROM dbo.InternalAddressBase WHERE parentid = @userId DELETE FROM mscrm_config..SystemUserOrganizations WHERE CrmUserId = @userid AND OrganizationId = @orgid DELETE FROM mscrm_config..SystemUserAuthentication WHERE authinfo = @authinfo DELETE FROM mscrm_config..SystemUser WHERE id = @MSCRMUserID /* rollback */ COMMIT
Pourquoi ne pas simplement désactiver les utilisateurs?
@Guidopreite Parce que nous testons des logiciels construits autour d'insertion de nouveaux utilisateurs. Si nous les désactivons, nous ne pouvons toujours pas réutiliser le compte d'utilisateur pour l'insérer à nouveau.