Category: Sitecore

A colleague at large university asked my thoughts on using Drupal for enterprise web content management (WCM).

Drupal has its uses, but I only recommend it for point solutions or, if in large-scale use, for cookie-cutter things where all the Drupal instances are configured almost identically and share little content. I generally do not recommend it for enterprise-wide WCM.

I wrote:

I manage a Sitecore installation that’s integrated with an enterprise Active Directory.

We have over 11,000 accounts in our Active Directory. I needed a list of the Sitecore users, who are only a small percentage of the 11,000.

We have nothing in Active Directory that sets them apart, like group membership.

We architected our solution so that users are never assigned directly to items; users are members of Sitecore roles, and we assign Sitecore roles to items. All I have to do is rifle through all my Sitecore roles.

So how do I find my users? It took a little C#. Here’s the core code:

var roles = Sitecore.Security.Domains.Domain.GetDomain("sitecore").GetRoles();
foreach (var role in roles)
{
    foreach(var roleMember in Sitecore.Security.Accounts.RolesInRolesManager.GetRoleMembers(role, false))
    {
        if (roleMember.AccountType == AccountType.User)
        {
            var userObject = Sitecore.Security.Accounts.User.FromName(roleMember.Name, false);
 
            // only adding SMU domain users
            if (userObject.Domain.Name == "myActiveDirectoryDomain")
                AddUserToList(userObject);
        }
    }
}

This gets all Sitecore domain groups and extracts all users who are a member of my corporate domain. Of course, you’ll replace myActiveDirectoryDomain with your own domain name.

I created a separate AddUserToList method to handle adding these items to a Dictionary:

private void AddUserToList(User user)
{
    if (!_users.ContainsKey(user.Name))
    {
        _users.Add(user.Name,user);
    }
}

After the core code runs, you’ll need to code your own stuff to spit out what’s in the dictionary.

Here’s what I used:

foreach(var user in _users)
{
    var row = new TableRow();
    OutputTable.Rows.Add(row);
 
    row.Cells.Add(new TableCell { Text = user.Value.Profile.UserName });
    row.Cells.Add(new TableCell { Text = user.Value.Profile.FullName });
    row.Cells.Add(new TableCell { Text = user.Value.Profile.Email });
 
    if (user.Value.Profile.FullName.Length == 0)
    {
        row.CssClass = "alert";
    }
 
    var rolesCell = new TableCell();
 
    foreach (var role in RolesInRolesManager.GetRolesForUser(user.Value, false))
    {
        if (role.Domain.Name == "sitecore")
        {
            rolesCell.Text += "
 " + role.Name;
        }
    }
 
    rolesCell.Text = rolesCell.Text.Substring(7);
    row.Cells.Add(rolesCell);
}

Note that I already had a Table named OutputTable on my ASPX page.

Tadaa! The result is a list of all my domain members who are Sitecore users.

How do you upgrade hardened content delivery (CD) environments? Ours are so hardened that you can’t even get to /sitecore/admin/UpdateInstallationWizard.aspx.

Here’s how. It can be tedious, but these make it easier:

1. CDs are mostly stripped-down instances of full Sitecore environments.
2. Any needed database changes are handled when upgrading the content mastering (authoring) environment.

You only need to do 3 things on CDs.

But first, two notes:

1. If you upgrade the CDs before you’ve upgraded the content mastering (CM) environment, you may have unstable CDs until the CM upgrade is done.
2. Sitecore’s .update files are really Zip files. Just open it with your favorite Zip program, like 7-Zip, and it works like any other Zip file.

For each update file, do the following three steps. You must perform them in the release order of the update files, starting with the oldest release.

1. Add new or changed files

Extract everything in the addedfiles and changedfiles directories of the update file. You’ll extract them over the web root. Tell your Zip program to overwrite existing files.

2. Delete files no longer needed

This is the hardest part. Inspect the update package’s deletedfiles and deletedfolders directories of the update file. Every file (not folder) under each corresponds to a file or folder under your web root that needs to be trashed.

Note the wording: “every file“. For example, in Sitecore 6.5.0 rev.110602_fromv640rev101012_2.update, there is a file named AuthoringFeedback under deletedfolders\sitecore\shell\Applications\Analytics. That means you would delete the directory at sitecore/shell/Applications/Analytics/AuthoringFeedback under the web root.

You may have to dig deeply and thoroughly to find all files and directories.

3. Edit .config files.

Do all .config file changes that correspond to the update package you just handled. A list of .config file changes are at http://sdn.sitecore.net/Products/Sitecore%20V5/Sitecore%20CMS%206/ReleaseNotes/webConfig.aspx.

Wrapping up

If you’re going through multiple upgrades, it’s tempting to do all them at once–do all the file additions at once, then all the file deletions, and then do all the .config changes. This might work as long as you work through the update files in their release order, starting with the oldest release, and if Sitecore didn’t delete something and add it back or vice versa.

For example, suppose you were doing four updates at once. In update #2, a file named x.png was deleted, but then it was added back in update #4. If you do all your file additions first, then do all deletions 2nd, your final state will have no x.png.

As long as you’ve been careful and did the CM environment upgrade first, the CDs should “just work” when done.