From The Field: Posts http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/AllPosts.aspx From The Field RSS feed Wed, 22 May 2013 02:12:33 GMT Microsoft SharePoint Foundation RSS Generator 60 en-US From The Field: Posts http://sharepoint.microsoft.com/blogs/fromthefield/_layouts/images/homepage.gif http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/AllPosts.aspx Customizing the MySiteCleanup job http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/ViewPost.aspx?ID=163 Body:

One issue that always comes up at my customers is the MySiteCleanup Job. They are not satisfied with the default implementation that SharePoint provides, and they want to change that way it behaves. Some feature requests for the job that I ran into so far with my various customers:

 

-        No “grace” period till a user (and later his MySite!!!) is deleted after missing from an Import
-        Violation of data privacy by granting MySite access to the manager
-        Modification of the Emails send out (The My Site of "User" is scheduled for deletion. As their manager you are now the temporary owner of their site[…])
-        Splitting requests for the job tasks, so each step can be toggled on/off by itself (usually caused by the manager issue)
-        No (supported) way to “stop” a site deletion once it was started
 
While most of these requests are “nice to have”, the manager issue is usually the one that kills the MySiteCleanup Job. Under German (and also EU) data protection laws, granting a manager access to his employees private files is a big no, and letting the Betriebsrat (Workers council) know about it is a sure way to turn it off. (It’s a sure way to turn almost any collaboration feature in SharePoint off, I did mention we have tight data protection laws?)
 
There is a way to completely modify the way this job is behaving. While this topic is coming up again and again (at least for me), there are very few resources that actually talk about how to modify this behavior but first let’s have a small review of the default implementation. Chun Liu’s Blog  published a small flowchart on what exactly it does, or check Spence’s blog for a bit more details about it.
 
1.      Cleanup user profiles
a.      Set the owner to the manager
b.      Inform the manager that he is owner
c.      Schedule site for deletion
d.      Delete Userprofile
2.      Cleanup MySites
a.      Send a reminder email after 11 days
b.      Delete the site after 14 days
 
One important thing to mention is that this job is the only place where SharePoint will remove an old user profile (there is no longer a “3-miss and you are out” policy in the UPA import). So turning this job “off” will leave you with all old user profiles in your UPA.
 
What is interesting is that the steps in the 1st section can be modified. Basically the steps 1.a to 1.c are implemented in the Class MySiteProfileHandler and the profile is actually deleted if the method PreProfileDeleted() returns true. This is also the class that can be replaced by a custom implementation. To replace this class, you need to create your own version, which implements the IProfileEventInterface.
 
One thing that is a bit awkward about this implementation is that the class “only” implements 1.a -1.c. So, even if you replace it, you will still have the old implementation of the 2nd part of the job “active”. But since you are not able to schedule a site for deletion in your custom code, the 2nd part of the job does actually nothing at all. This means you also have to make sure you handle the MySite deletion properly. Since your code won’t be revisited after you gave your consent to delete the user, you need to make sure you implement an alternative workflow. 3 possible solution would be to either postpone the deletion of the user by X Days (Until you handled the MySite yourself), or create a small site workflow, attached to the MySite, that will cause the MySite to “self-destruct” after the given time (This wasn’t possible when the default timer job was implemented, but you have the option now), or backup and delete it right away (This would allow for a different retention of the MySite backups)
 
So once you have created the new class and put it into the GAC, the one step that is missing in order to use it in SharePoint is to register your custom implementation. To do this you have to fall back to a stsadm. You need to register the new class to running stsadm -o profiledeletehandler -type <full assembly path>  http://technet.microsoft.com/en-us/library/cc263114(v=office.12).aspx  . This will store the type you entered in an internal (sorry, calling internal methods is also unsupported) property ProfileDeleteEventHandler of the MySiteCleanUpJob Instance.
After that is done, SharePoint will apply your logic to the MySiteCleanup job, and you are set.
 
The are some drawbacks that you have to consider:
-        Needs to be registered via STSADM
-        Needs an assembly deployed into the GAC
-        Not very transparent for a new Admin
-        Unable to access the internal MySiteDeletion “Workflow” from my custom code – Need to reinvent the wheel
 
The option I would have loved the most, is the ability to configure how this process behaves right out of the box, but this is as close as we can get. Finding this option kind of surprised me, since there are very few places in SharePoint that use Interfaces (I love unit tests)
 
 
I hope you will find this information usefull. If there are any questions, feel free to ping me.

 

 

 

 

 

Category: Customization; My Site; SharePoint 2010; stsadm; MOSS 2007; SharePoint 2013
Published: 4/23/2013 9:01 AM
]]> Heiko Hatzfeld Customization; My Site; SharePoint 2010; stsadm; MOSS 2007; SharePoint 2013 Tue, 23 Apr 2013 15:55:42 GMT http://sharepoint.microsoft.com/blogs/fromthefield/Lists/Posts/ViewPost.aspx?ID=163