Hi,
I'm currently having an issue with AD account names. If a user leaves and the account is removed from AD and MOSS, then another user is set up with the same name it causes problems.
Im aware I can run the following STSADM command to resolve this;
Stsadm –o migrateuser –oldlogin xxx\xxxx –nerwlogin xxx\xxxx ?ignorehistory
but, at the point the user is created, it creates a massive block in SQL, causing site collections to become unresponsive and timing out.
offending code;
(@P1 uniqueidentifier,@P2 int,@P3 int,@P4 int,@P5 varbinary(19),@P6 bit,@P7 bit,@P8 bit,@P9 nvarchar(6),@P10 int,@P11 varbinary(19),@P12 nvarchar(12),@P13 nvarchar(11),@P14 nvarchar(24),@P15 nvarchar(1),@P16 nvarchar(1),@P17 nvarchar(1),@P18 nvarchar(1),@P19 nvarchar(1),@P20 nvarchar(1),@P21 nvarchar(1),@P22 nvarchar(1),@P23 nvarchar(1),@P24 nvarchar(1),@P25 nvarchar(1),@P26 bit,@P27 bit,@P28 nvarchar(45),@P29 nvarchar(64),@P30 nvarchar(19),@P31 bit,@P32 nvarchar(1),@P33 nvarchar(1),@P34 nvarchar(1),@P35 nvarchar(1),@P36 nvarchar(1),@P37 nvarchar(1),@P38 nvarchar(1),@P39 nvarchar(1),@P40 nvarchar(6),@P41 int,@P42 int OUTPUT)SET NOCOUNT ON; DECLARE @DN nvarchar(256),@LN nvarchar(128),@@DocUIVersion int,@@S uniqueidentifier,@@Level tinyint; DECLARE @ItemId int; DECLARE @@iRet int; DECLARE @ExtraItemSize int; SET @@Level = 1; SET @@S=@P1; BEGIN TRAN EXEC @@iRet = proc_SecRemoveUserFromSite @@S, @P2, @P3 SELECT @ItemId = @P4 IF @@iRet <> 0 BEGIN ROLLBACK TRAN; GOTO DONE; END IF NOT EXISTS( SELECT tp_ID FROM UserData WHERE tp_ListId = 'E477331C-C6C9-46C9-8907-7A91D1CF425D' AND tp_ID = @ItemId AND tp_Level = 1 AND tp_RowOrdinal =0) BEGIN SELECT @ExtraItemSize = 0 EXEC @@iRet = proc_AddListItem @SiteId = 'CA4D17A9-D2E0-4314-95D9-CE9DD82A2ED1',@WebId='407AFC22-532C-4ABC-A87B-5CFB2ECA9A23',@ListID = 'E477331C-C6C9-46C9-8907-7A91D1CF425D',@RowOrdinal = 0,@ItemId = @ItemId OUTPUT,@ItemDirName=@DN OUTPUT,@ItemLeafName=@LN OUTPUT,@UserID = -1,@tp_Author = @ItemId,@tp_Editor = @ItemId,@TimeNow = '20130821 15:25:21',@ServerTemplate = 112,@Basetype= 0,@Level= 1,@tp_GUID =NULL,@AddNamespace=1,@CheckDiskQuota=1, @tp_ContentTypeId = @P5, @bit2 = @P6, @bit3 = @P7, @bit4 = @P8, @tp_ContentType = @P9, @tp_ModerationStatus = @P10, @Size = 16, @ExtraItemSize = @ExtraItemSize ,@acl=0xF3FE0000010000000000000000000000; IF @@iRet <> 0 BEGIN ROLLBACK TRAN; GOTO DONE; END END ELSE BEGIN SET @@Level=1; SELECT @ExtraItemSize = 0 EXEC @@iRet = proc_UpdateListItem @SiteId='CA4D17A9-D2E0-4314-95D9-CE9DD82A2ED1',@WebId='407AFC22-532C-4ABC-A87B-5CFB2ECA9A23', @ListID = 'E477331C-C6C9-46C9-8907-7A91D1CF425D', @ItemID=3228, @RowOrdinal = 0,@ReturnRowset = 1,@ItemDirName=@DN OUTPUT,@ItemLeafName=@LN OUTPUT,@UserId=-1,@TimeNow = '20130821 15:25:21',@SystemUpdate=1,@MajorVersionsLimit=0,@MajorMinorVersionsLimit=0, @NewUIVersion = @@DocUIVersion OUTPUT,@Level=@@Level OUTPUT,@IsDocLib=0, @tp_ContentTypeId = @P11, @nvarchar1 = @P12, @nvarchar3 = @P13, @nvarchar4 = @P14, @ntext2 = @P15, @int1 = @P16, @int2 = @P17, @int3 = @P18, @int4 = @P19, @bit1 = @P20, @int5 = @P21, @int6 = @P22, @int7 = @P23, @int8 = @P24, @int9 = @P25, @bit2 = @P26, @bit3 = @P27, @nvarchar6 = @P28, @nvarchar7 = @P29, @nvarchar9 = @P30, @bit4 = @P31, @nvarchar10 = @P32, @nvarchar11 = @P33, @nvarchar12 = @P34, @nvarchar13 = @P35, @nvarchar14 = @P36, @nvarchar15 = @P37, @ntext3 = @P38, @nvarchar17 = @P39, @tp_ContentType = @P40, @tp_ModerationStatus = @P41, @tp_ItemOrder = 322800.000000000, @Size = 374, @ExtraItemSize = @ExtraItemSize ,@acl=0xF3FE0000010000000000000000000000; IF @@iRet <> 0 BEGIN ROLLBACK TRAN; GOTO DONE; END
EXEC proc_ClearLinks @@S,@DN,@LN,@@Level,'E241F186-9B94-415C-9F66-255CE7F86235';
EXEC proc_ClearLinks @@S,@DN,@LN,@@Level,'82B26987-3381-4B90-9FE8-5630C8ACA7FA';
EXEC proc_ClearLinks @@S,@DN,@LN,@@Level,'A49AE959-3D4E-477B-AB68-5ED6705AEAA9'; END ; COMMIT TRAN; DONE: SELECT @P42 = @@iRet
Is there a permenant way this can be avoided in the future?
