Recently I was working with a client that publishes content from a secure SharePoint site to a public SharePoint site. This publishing involves the use of the SPListItem.Copy command to copy a ListItem from the secure site to the public site. The public and secure sites both have the same content types, but use different page layouts to display the same data. Therefore, the Copy function makes the most sense and requires the least amount of effort.
However, since SharePoint is built on a database, SPListItem.Copy can’t just do a copy like a file system can. Instead, it must read and write the requisite data from/to the database. As a result, validation takes place on the data that’s being written. Specifically, user validation occurs again. Normally, this isn’t a problem because users don’t change that often.
In the case of this client, though, one of their content editors had left her position and her Active Directory account was deleted. As a result, the copy operation was failing because the user could not be found. Fortunately, the simple fix was to recreate the user account in a disabled state. That way SharePoint could find the user in AD and complete the copy operation, but the user could no longer log in.
The moral of the story is that SharePoint is sensitive to user accounts because it relies on AD (or some other identity management system) for validation. Therefore, your best option is to disable a user account or change permissions instead of removing a user entirely.
