Part 3, Converting users from CommunityServer to DotNetNuke

Two updates on the series in two days? Woah! So before you get into Part 3 of my CommunityServer to DotNetNuke series catch up if you haven’t read the previous posts.

A brief background: I had a number of websites running on CommunityServer 2.1, I decided it was finally time to ditch CommunityServer due to the change in their licensing model and pricing that made it not good for the small guy. This series of blog posts is about how to convert your CommunityServer based sites to DotNetNuke.

Series of Posts:
Part 1: An Introduction
Part 2: DotNetNuke Installation
Part 3: Converting users from CommunityServer to DotNetNuke
Part 4: Getting the conversion tables ready for CS  to DNN
Part 5: Moving Forum threads from CommunityServer to DotNetNuke
Part 6, Community Server to DotNetNuke Moving Forum replies and attachments
Part 7: CommunityServer to DotNetNuke handling URLs

This is Part 3, Converting Users from CommunityServer to DotNetNuke

In this part we’re going to talk about the process used to get users from CommunityServer into DotNetNuke. This part uses some of the SQL scripts that you can download from the CStoDNN project on codeplex http://cstodnn.codeplex.com, before we talk specifically about the user accounts let’s cover some details of the SQL scripts in that project.

  1. You will need to be able to access both the CommunityServer database and the DotNetNuke database with the same user account, the scripts assume this to be the case.
  2. The scripts have a number of STRINGS that need to be swapped out before executing them (do a find and replace in each of the scripts for the following strings
    1. SOURCEDB = the name of the CommunityServer database
    2. TARGETDB = the name of the DotNetNuke database
    3. forumMODULEID = the Module ID of the Forum module (see Part 2 for where to locate this)
    4. PORTALID = should be 0 unless you are using a different portal
    5. [email protected] = should be the email address you want to define for the email address of each portal, you can change this later in the Forum settings
    6. WEBSITENAME = The name of your website, this is the “name” that forum email notifications come from
  3. The SQL scripts are numbered, we are only dealing with the first script in this blog post, CsToDNN_1.sql (there are other things going on in this script, we will cover those in the next blog post)
  4. The default configuration for CommunityServer passwords is hashed, while DotNetNuke encrypts them. So changing things causes some issues. You are going to have to copy the MACHINEKEY section of the web.config file from your CommunityServer web.config file and replace it in DotNetNuke’s web.config. This will cause DNN to use hashed passwords as well. We go into details on this in a later blog post.

So let’s talk about the user conversion process for users. Users and data for users in CommunityServer are stored in the following tables, there is likely other info but we aren’t pulling over profile data, just the basics

  • aspnet_membership
  • aspnet_users

In DotNetNuke we’re going to insert User data into the following tables

  • aspnet_membership – standard aspnet_membership tables holding out basic data, userid, password, password format, password salt
  • aspnet_users – standard aspnet_users table holding the username, the userid, email address
  • users – a DotNetNuke table storing basic user info, username, integer based userid
  • userportals – mapping DotNetNuke users to Portals in the database (portals are individual websites in DNN)
  • userroles – storing the User/Role relationships in DotNetNuke for permissions
  • userprofile – stores DotNetNuke user profile info
  • forum_users – a mapping of Forum information to users
  • Conversion_users - a table created in the SQL script, used for referencing communityserver ids and dotnetnuke ids

The Script does the following for users (we skip over a few things not related to users, covered in the next blog post)

  • Changes the ADMIN account in DotNetNuke to ADMIN2, this happens because in all likelyhood your CommunityServer database already has an ADMIN account and if you run the scripts you’ll get a conflict
  • Resets the password/format/salt for the existing users in the DNN database (this should just be for HOST and ADMIN2 as you should be in a clean DotNetNuke install). The passwords are reset to ‘dnnpassword’ so after you’re done with everything be sure to reset the passwords!
  • Drops the conversion_users table from the DotNetNuke database if it exists
  • Creates the conversion_users table
  • Gets all users from the CommunityServer aspnet_users table into the DotNetNuke aspnet_users table
  • Gets info from CommunityServer aspnet_membership table into the DotNetNuke aspnet_membership table
  • Inserts data into the DotNetNuke Users table
  • Insert into DotNetNuke UserPortals table (associates the users with PortalID 0)
  • Insert into DotNetNuke UserRoles table (add users to Registered Users role)
  • Insert into DotNetNuke Forum_Users table, lots of data going in here, default settings for users primarily

There are a number of other things going on in this script, I’ll talk about those in the next blog post!

A reminder, for all of these scripts, and the conversion process, I recommend you do frequent backups! I found that I repeated a lot of steps while testing and writing these scripts, doing backups saved me from having to start over every time. Though ideally these scripts will work for you out of the box, and you won’t need to change/rerun them, but better safe then sorry.

(note: This script assumes your Portal has the RegisteredUsers role in DotNetNuke as RoleId =1)

Recent Comments

There are currently no comments. Be the first to make a comment.

Add Comment

Please add your comment by filling out the field(s) below. Your comment may need to be approved before it becomes visible.
Enter your first name for display with the comment
Enter your last name for display with the comment.
Enter your comment here.
If you can't type Human2 in, you can't post, plain and simple.
Submit Comment Cancel

Chris Hammond

Chris Hammond

is a father, husband, leader, developer, photographer and car guy. Chris has long specialized in ASP.NET and DotNetNuke (DNN) development, so you will find a variety of posts relating to those topics. For more information check out the about Chris Hammond page.

If you are looking for DotNetNuke consulting please visit Christoc.com Software Solutions

Find me on Twitter, GitHub and LinkedIn.