As I mentioned in my previous post (Replace Field Values) I'm currently trying to solve the issue of broken links throughout the various sites that I've upgraded and moved around. The gl-replacefieldvalues command was the first of three that I've created. This second command, called gl-applyupgradeareaurlmappings, is very similar to the gl-replacefieldvalues command but it is a bit specialized.
I've created this command to address the list items in the special Upgrade Area Url Mappings list (http://[portal]/Lists/98d3057cd9024c27b2007643c1/AllItems.aspx). Instead of taking in a search string and replace string like the other command does I use this list as the source for the search and replace string. The intent is to prevent the user from having to deal with the spsredirect.aspx page when clicking links within a web application.
It's important to note though that I've limited this command to be scoped at the web application level and below and the upgrade list must exist in the web application being targeted. I went back and forth on whether I wanted to allow a farm scope but in the end decided against it. I also considered allowing you to target one application but reference the list from another but the reality of that was that it would be much too difficult to do a reliable replace due to the fact that the URLs in the list are server relative so I simply wouldn't be able to know which to make absolute and which web app to use for the absolute path.
I haven't been able to do a significant amount of testing with this but it seems to work fairly well - I was concerned about the order in which the replacements occur which could result in funny things happening but in the test runs that I did the replacements seemed to work just fine (if anyone finds differently please let me know and I'll see if I can work it out).
Because of this and due to the general nature of making batch content replacements I strongly suggest using the "-test" parameter and verifying all the changes that will be attempted before you execute for real - if you don't and things get messed up then you'll have a nice new command to create: "revertpreviouscheckins" sounds like a good name :)
The large bulk of this code is just a series of methods with different loops in them to handle the various scoping capabilities. The core code itself is simply looking at all fields of type string and doing a regular expression replace using the information from the upgrade list. Like the gl-replacefieldvalues command I've added the ability to dump all changes to a log file as well as to run the command in a "test" mode where it will show you what it would change but not actually make the change (as mentioned above) - Again, I'd strongly recommend you use this first to verify all the changes that will be made. The core code is shown below:The syntax of the command I created can be seen below.
C:\>stsadm -help gl-applyupgradeareaurlmappings stsadm -o gl-applyupgradeareaurlmappings Replaces all occurrences of the V2 server relative URLs with the corresponding V3 server relative URLs as specified in the Upgrade Area Url Mappings list: "http://[portal]/Lists/98d3057cd9024c27b2007643c1/AllItems.aspx" Parameters: -url <url to search> -scope <WebApplication | Site | Web | List> [-field <field name>] [-useinternalfieldname (if not present then the display name will be used)] [-quiet] [-test] [-logfile <log file>] [-publish]
Here’s an example of how to replace all occurrences of the V2ServerRelativeUrls with the corresponding V3ServerRelativeUrl:
stsadm -o gl-applyupgradeareaurlmappings -url "http://intranet/" -scope webapplication -logfile "c:\replace.log" -publish
If you wish to filter by field name you can specify either the display name or the internal name. Note that if you specify the internal name you must also add the "useinternalfieldname" parameter - if you don't use the internal field name then be aware that you may be updating more than the field you intended as the display name is not always unique (but in most cases it is).
If you don't want your changes published then don't specify the publish parameter. However, specifying the publish parameter will not publish items that were previously checked out. If an item can be published and it requires approval then specifying the publish parameter will also cause the item to be approved.