<?xml version="1.0" encoding="UTF-8"?><rss version="2.0"
	xmlns:content="http://purl.org/rss/1.0/modules/content/"
	xmlns:dc="http://purl.org/dc/elements/1.1/"
	xmlns:atom="http://www.w3.org/2005/Atom"
	xmlns:sy="http://purl.org/rss/1.0/modules/syndication/"
		>
<channel>
	<title>Comments on: Developing Migration Methodologies</title>
	<atom:link href="http://www.sharepointdan.com/2008/02/10/developing-migration-methodologies/feed/" rel="self" type="application/rss+xml" />
	<link>http://www.sharepointdan.com/2008/02/10/developing-migration-methodologies/</link>
	<description>Connecting... Collaborating... Communicating...</description>
	<lastBuildDate>Wed, 01 Feb 2012 08:05:14 +0000</lastBuildDate>
	<sy:updatePeriod>hourly</sy:updatePeriod>
	<sy:updateFrequency>1</sy:updateFrequency>
	<generator>http://wordpress.org/?v=3.3.1</generator>
	<item>
		<title>By: Dan</title>
		<link>http://www.sharepointdan.com/2008/02/10/developing-migration-methodologies/comment-page-1/#comment-27</link>
		<dc:creator>Dan</dc:creator>
		<pubDate>Wed, 28 Jan 2009 04:41:13 +0000</pubDate>
		<guid isPermaLink="false">http://sharepointdan.com/?p=9#comment-27</guid>
		<description>So if it were me, I would do an LDIFDE of the AD - specifically the OUs with user information.  I would then take that and import it into SQL Server using a little data parsing to clean things up.  From there I would hope and pray that stsadm -o migrateuser would be able to migrate the permissions from the AD authentication provider to the SQL server authentication provider.  If so I would batch script the entire thing and go listen to some Jack Johnson.</description>
		<content:encoded><![CDATA[<p>So if it were me, I would do an LDIFDE of the AD &#8211; specifically the OUs with user information.  I would then take that and import it into SQL Server using a little data parsing to clean things up.  From there I would hope and pray that stsadm -o migrateuser would be able to migrate the permissions from the AD authentication provider to the SQL server authentication provider.  If so I would batch script the entire thing and go listen to some Jack Johnson.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: joelsef.blogspot.com/</title>
		<link>http://www.sharepointdan.com/2008/02/10/developing-migration-methodologies/comment-page-1/#comment-25</link>
		<dc:creator>joelsef.blogspot.com/</dc:creator>
		<pubDate>Wed, 28 Jan 2009 01:05:49 +0000</pubDate>
		<guid isPermaLink="false">http://sharepointdan.com/?p=9#comment-25</guid>
		<description>Here&#039;s one for ya: What about moving 10000+ AD accounts used for a WSS 2.0 site into an ASPNET SQL Server user store for use with a Membership Provider for MOSS?</description>
		<content:encoded><![CDATA[<p>Here&#8217;s one for ya: What about moving 10000+ AD accounts used for a WSS 2.0 site into an ASPNET SQL Server user store for use with a Membership Provider for MOSS?</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: Dan</title>
		<link>http://www.sharepointdan.com/2008/02/10/developing-migration-methodologies/comment-page-1/#comment-24</link>
		<dc:creator>Dan</dc:creator>
		<pubDate>Wed, 28 Jan 2009 00:24:05 +0000</pubDate>
		<guid isPermaLink="false">http://sharepointdan.com/?p=9#comment-24</guid>
		<description>I&#039;m aware of the stsadm -o migrateuser command and the ability to move a user&#039;s permissions from domain A to domain B as mentioned above, however this becomes daunting when you&#039;re doing a piecemeal migration of site collections from an Enterprise SharePoint system in domain A to an Enterprise SharePoint system in domain B, continuously having to repermission the user&#039;s data on both sides so that they have to maintain ownership.  This unfortunately isn&#039;t really solved by the migrateuser command as that&#039;s a one time migration - new data requires that it be re-run.

What you could do I suppose is to write a script that enumerates all users that are on a site and then map that to the new domain when the site is moved, but it still is something that has to be considered so that a user maintains owernship throughout the process.</description>
		<content:encoded><![CDATA[<p>I&#8217;m aware of the stsadm -o migrateuser command and the ability to move a user&#8217;s permissions from domain A to domain B as mentioned above, however this becomes daunting when you&#8217;re doing a piecemeal migration of site collections from an Enterprise SharePoint system in domain A to an Enterprise SharePoint system in domain B, continuously having to repermission the user&#8217;s data on both sides so that they have to maintain ownership.  This unfortunately isn&#8217;t really solved by the migrateuser command as that&#8217;s a one time migration &#8211; new data requires that it be re-run.</p>
<p>What you could do I suppose is to write a script that enumerates all users that are on a site and then map that to the new domain when the site is moved, but it still is something that has to be considered so that a user maintains owernship throughout the process.</p>
]]></content:encoded>
	</item>
	<item>
		<title>By: v-2nishc@hotmail.com</title>
		<link>http://www.sharepointdan.com/2008/02/10/developing-migration-methodologies/comment-page-1/#comment-23</link>
		<dc:creator>v-2nishc@hotmail.com</dc:creator>
		<pubDate>Tue, 27 Jan 2009 17:55:43 +0000</pubDate>
		<guid isPermaLink="false">http://sharepointdan.com/?p=9#comment-23</guid>
		<description>i hope you would be aware of the fact that with the new stsadm -o migrate user tool, you can migrate your users to the new domain in sharepoint.</description>
		<content:encoded><![CDATA[<p>i hope you would be aware of the fact that with the new stsadm -o migrate user tool, you can migrate your users to the new domain in sharepoint.</p>
]]></content:encoded>
	</item>
</channel>
</rss>

