Migrating Sitecore users from one instance to another without losing their passwords using SQL 2008 R2.

You can copy Sitecore users from one instance to another using a package however their passwords will be reset. If you want to copy users without losing passwords The Inside Corner site has a page that describes how to migrate Sitecore users from one installation to another: http://www.theinsidecorner.com/en/SiteAdmins/SiteSecurity/SitecoreAccounts/MigratingAccounts.

This description is a bit out of date if you are using the database script method with SQL Server 2008 R2 because the SSMS wizard has been changed.
Here’s how to do it with SQL 2008 R2:

  1. Right click on the core database and choose Generate Scripts
  2. If SSMS shows an Introduction page, click next
  3. Select specific database objects
  4. Expand Tables
  5. Select all tables with a name starting with aspnet_
  6. Click next
  7. Select the advanced button
  8. Change “Script DROP and CREATE” to Script DROP and CREATE
  9. Change “Types of data to script” to Schema and data
  10. Choose whatever option to save the script that works for you, clipboard, file or new query editor window.

PS: I suspect this would work with any ASP.NET site that uses the membership provider but who does regular asp.net sites anymore?

How to redirect a specific domain to a sublevel page on a different domain using URL Rewrites in IIS7

Anytime I have to look up something twice in three days I figure I might need that info again. Sometimes you have multiple domains pointing to the same site one of which might be a “marketing domain”. Here’s how to redirect a domain request to a page on a different domain.

  • Select URL Rewrite
  • Select Blank rule
  • Enter the pattern

     NOTE: This means any character, any number of repetitions.

  • Expand Conditions if not already expanded and Click “Add”.
  • Enter

    for “Condtion Input”. (Curly braces are required)

  • Set “Check if input string” to “Matches the Pattern”
  • Pattern

    where domain is the domain to redirect. (The part


    makes www. optional

  • Enter the URL such as
  • Enter “Redirect” for action
  • Redirect type should be 302 if this is temporary, 301 for permanent redirects. Browsers cache 301 redirects so if it changes in the future, it may take a while for users to know about it.
  • Another way to redirect mobile devices to m. subdomain

    Mortaza Kamal Nourestani posted here a way to ensure that mobile devices are served at a “m.” subdomain site, and that desktop devices are served at the normal domain.
    Here’s my take on that using a resolver in the httprequest pipeline. This only requires adding a class, and .config file with no modifications to existing files. I’ve reused his IsMobileBrowser method.

    using System;
    using System.Linq;
    using System.Web;
    using Sitecore.Pipelines.HttpRequest;
    namespace Samples.Extensions.Resolvers
        public class MobileSiteResolver : Sitecore.Pipelines.HttpRequest.SiteResolver
            public override void Process(HttpRequestArgs args)
                string absoluteUri = String.Format("{0}://{1}{2}", HttpContext.Current.Request.Url.Scheme,
                string host = HttpContext.Current.Request.Url.Host;
                if (host.StartsWith("m."))
                    if (!IsMobileBrowser(HttpContext.Current))
                        host = host.Replace("m.", "");
                        absoluteUri = absoluteUri.Replace(HttpContext.Current.Request.Url.Host, host);
                    if (IsMobileBrowser(HttpContext.Current))
                        host = String.Format("{0}.{1}", "m", HttpContext.Current.Request.Url.Host);
                        absoluteUri = absoluteUri.Replace(HttpContext.Current.Request.Url.Host, host);
            public static bool IsMobileBrowser(HttpContext context)
                if (context.Request.Browser.IsMobileDevice)
                    return true;
                if (context.Request.ServerVariables["HTTP_X_WAP_PROFILE"] != null)
                    return true;
                if (context.Request.ServerVariables["HTTP_ACCEPT"] != null &&
                    return true;
                if (context.Request.ServerVariables["HTTP_USER_AGENT"] != null)
                    //Create a list of all mobile types
                    string[] mobiles =
                            "midp", "j2me", "avant", "docomo",
                            "novarra", "palmos", "palmsource",
                            "240x320", "opwv", "chtml",
                            "pda", "windows ce", "mmp/",
                            "blackberry", "mib/", "symbian",
                            "wireless", "nokia", "hand", "mobi",
                            "phone", "cdm", "up.b", "audio",
                            "SIE-", "SEC-", "samsung", "HTC",
                            "mot-", "mitsu", "sagem", "sony"
                            , "alcatel", "lg", "eric", "vx",
                            "NEC", "philips", "mmm", "xx",
                            "panasonic", "sharp", "wap", "sch",
                            "rover", "pocket", "benq", "java",
                            "pt", "pg", "vox", "amoi",
                            "bird", "compal", "kg", "voda",
                            "sany", "kdd", "dbt", "sendo",
                            "sgh", "gradi", "jb", "dddi",
                            "moto", "iphone"
                    //Loop through each item in the list created above
                    //and check if the header contains that text
                    if (mobiles.Any(s => context.Request.ServerVariables["HTTP_USER_AGENT"].ToLower().Contains(s.ToLower())))
                        return true;
                return false;

    To enable this resolver create a config file in /app_config/includes/ such as mobiledeviceresolver.config with these content:

    <configuration xmlns:patch="http://www.sitecore.net/xmlconfig/">
                    <processor patch:before="*[@type='Sitecore.Pipelines.HttpRequest.SiteResolver, Sitecore.Kernel']"
                    type="Samples.Extensions.Resolvers.MobileSiteResolver, Logica.Extensions"/>

    The usual caveats apply, this is untested in a production environment, test throughly before using. It could also be significantly optimized for performance.

    Handy Sitecore Admin URLs

    A while back one of our enterprise Sitecore clients* called in a panic because they could not access the Sitecore desktop. Somehow the English language item had gotten deleted overnight. We told them about the dbbrowser page where they were able to undo the damage. I realized not every Sitecore developer knows all of these so compiled a quick list of handy “secret” admin URLs for Sitecore. When I need one, I need it in a hurry so thought I’d just make a list.
    • Kick users page: /sitecore/shell/Applications/login/users/Kick.aspx
    • DB Browser (when you can’t get to the content editor) /sitecore/admin/dbbrowser.aspx
    • Show Config /sitecore/admin/showconfig.aspx
    • Unlock Admin /sitecore/admin/unlock_admin.aspx
    • Cache /sitecore/admin/cache.aspx
    • Upgrade/Package wizard /sitecore/admin/updateinstallationwizard.aspx
    • Log Viewer /sitecore/shell/applications/reports/logviewer.aspx

    I’ll update as I compile more. Drop me a note if you know of one I missed.


    *Obviously can’t name the client but they are part of one of the top three most prestigious Universities in the United States.

    Best practice for managing Rewrite Rules in IIS7

    When moving a client from an old site to a new one, you frequently need to redirect Legacy URLs to new ones to maintain SEO. IIS 7 Rewrite Rules with Rewrite Maps easily accomplish this. A Rewrite Map is simply a subset of a rule with a list of source/destinations. With a bit of massaging, you can take a Excel workbook and export to a map.

    The only problem with IIS rewrites are they are added to the web.config file, which for a Sitecore app is already 4000+ lines. Here’s how to keep it clean:
    Add the section everything inclusive of the <rewrite> tags just before the ending </system.webServer> tag.

        {lots of stuff here}
                <rewriteMaps configSource="RewriteMaps.config" />
                <rules configSource="RewriteRules.config" />

    Add two files RewriteMaps.config and RewriteRules.config (samples below) to the web root. IIS will save any changes and additions to the external config files instead of the web.config.

    In my starter files (below) are two rewrite maps, Legacy URLs and Marketing URL’s. Legacy would be for the old to new pages which will likely never change, and Marketing rules is for advertising campaigns etc. Keeping them segregated makes updates easier.


        <rewriteMap name="Legacy URLS">
            <add key="/about_directory.asp" value="/About/Find-an-Office.aspx" />
            <add key="foo" value="bar" />
        <rewriteMap name="Marketing Rules">
            <add key="/jobs" value="/AboutUs/Careers.aspx" />


        <rule name="Redirect rule1 for Legacy URLS">
            <match url=".*" />
                <add input="{Legacy URLS:{REQUEST_URI}}" pattern="(.+)" />
            <action type="Redirect" url="{C:1}" appendQueryString="false" />
        <rule name="Rewrite rule1 for Marketing Rules">
            <match url=".*" />
                <add input="{Marketing Rules:{REQUEST_URI}}" pattern="(.+)" />
            <action type="Rewrite" url="{C:1}" appendQueryString="false" />

    One thing to note with this: If you make changes to either of these files manually (in a text editor) it seems that IIS Caches them. So, after your done editing either of those files you need to open the web.config file and re-save it so it forces a refresh.