The following module is available for download.

Module Name:     MZNS.UserImport
DNN Version:      DNN 3.0.13
Source Code:     No
Price:                 Free

http://www.mikez.com

During our testing 1000 users can be imported in just about 30 seconds (Intranet).

An online demo is available at the above link along with the download and instructions.  Please use the forum at this site to post any bugs, suggestions or questions.  There is no registration required to download the module or to post in the forum.

There are lots of things to consider when importing users when using Windows Authentication.  The Usernames will exist in the DNN tables as DOMAIN\username.  Therefore pay special attention to the Domain Name textbox and the requirements during imports, adding to roles and updating accounts.

Depending on the feedback on this module we are planning on adding an export option.  But again, there are complexities involved and we would like some specific feedback.  We have our own requirements for export and will most likely start there for the first version.

Please take the time to read the instructions and play with the online demo.  The "Import" link has obviously been disabled for the online demo.

mikez

This is a useful module. Thanks! One suggestion -- can you add additional import fields so that it updates the user created date, last login date and last password change date? And if these are not specified you could default them to the new record create date.

Thanks,

Jason

Jason,

I don't think the Create Date, Last Login Date & Last Paasword Change Date can or should be modified.  This would probably require directly touching the SQL table and bypassing the core user/membership functions.  This could violate security requirements in place at many sites related to storing log files, etc.

mikez

Mike,

Doesn't the new member API support this easily and safely?  I thought the DNN 2.x to DNN 3.x upgrade copied the last login & created date fields this.

Importing these fields seems like a very important feature to me. If you had a large list of users you built over a period of time, you would lose all your history. You would not know how many active users you have or be able to compare the number of signups versus prior months or years.

Here is the code I was looking at which made me think that there would not be problems with adding dates:

Dim objSuperUserInfo As New UserInfo
Try
objSuperUserInfo.UserID = Convert.ToInt32(dr("UserID"))
Catch
End Try
Try
    objSuperUserInfo.PortalID = Convert.ToInt32(dr("PortalID"))
Catch
End Try
Try
    objSuperUserInfo.IsSuperUser = Convert.ToBoolean(dr("IsSuperUser"))
Catch
End Try
Try
    objSuperUserInfo.Membership.Username = Convert.ToString(dr("Username"))
Catch
End Try
Try
    objSuperUserInfo.Membership.Approved = Convert.ToBoolean(dr("Authorized"))
Catch
End Try
Try
    objSuperUserInfo.Membership.CreatedDate = Convert.ToDateTime(dr("CreatedDate"))
Catch
End Try
Try
    objSuperUserInfo.Membership.Email = Convert.ToString(dr("Email"))
Catch
End Try
Try
    objSuperUserInfo.Profile.FirstName = Convert.ToString(dr("FirstName"))
Catch
End Try
Try
    objSuperUserInfo.Profile.LastName = Convert.ToString(dr("LastName"))
Catch
End Try
Try
    objSuperUserInfo.Membership.Password = Convert.ToString(dr("Password"))
Catch
End Try
Try
    objSuperUserInfo.Profile.City = Convert.ToString(dr("City"))
Catch
End Try
Try
    objSuperUserInfo.Profile.Country = Convert.ToString(dr("Country"))
Catch
End Try
Try
    objSuperUserInfo.Profile.PostalCode = Convert.ToString(dr("PostalCode"))
Catch
End Try
Try
    objSuperUserInfo.Profile.Region = Convert.ToString(dr("Region"))
Catch
End Try
Try
    objSuperUserInfo.Profile.Street = Convert.ToString(dr("Street"))
Catch
End Try
Try
    objSuperUserInfo.Profile.Telephone = Convert.ToString(dr("Telephone"))
Catch
End Try
Try
    objSuperUserInfo.Profile.Unit = Convert.ToString(dr("Unit"))
Catch
End Try

arrUsers.Add(objSuperUserInfo)

I could not find a reference to the lastlogin date though. Only the "createdate" so I am not sure how DNN handles this. But couldn't you add this using the new member API ?

Thanks,

Jason

Jason,

Are you asking that the "CreatedDate" be different than the date you actually import the record?

mikez

Mike

Love the module.  I too would like my own "CreatedDate" we are moving from IBS to DNN, we have 500 Users,  some have been using our IBS system for over two years, while others are relatively new.  It would be good to know who's new and who's not.

Lou

Jason/Lou,

I now understand.

I tried a quick test of adding "CreatedDate" with a date of "01/01/2003".
After an import the "CreatedDate" still showed as today.
There were no errors though.  I am thinking the memebership dll just shrugs it off.

I cannot find anywhere in the core (doesn't mean it's not there) where "CreatedDate" can actually be modified.  I've only got one eye open about now so I'll poke around the next few days.

mikez

The two fields I would like to see implemented are:

Jason

We have looked at the core code and cannot find if it is actually possible to force a change to the fields.  We tried to populate these fields and the resulting date was still the datetime of the import.  We still believe this is not possible per the membership dll. 

userObj.Membership.LastLoginDate
userObj.Membership.CreatedDate

Also, we still feel that modifying the these 2 fields goes against most security policies for Intranet sites.  It probably is not an issue for public web sites.

Anyone know if the membership provider actually allows these fields to be updated?

Any comments from those that must maintain logs per internal security policies?

mikez

Nice job on the UI!  A lot of thought went into this one.  The one thing I see missing in all of the import modules (and may be giving away an idea) is a field mapper for different source data files types.  You know, first row contains field names.... if not then use these columns, etc.  I think if it was more Microsoftish, there would be higher demand.  Not everyone knows SQL.

Again, great job on the module!  UI is sweet!

Wallew

Ant,

Try this site to move users from DNN2 to DNN3.  Look for "copyusers".  There is also a great calendar module. 
http://www.dnnworx.com 
-------------------------------------------------
While there are certainly more features that could be added to the MZNS.UserImport module our intention was to release a working, finished module that was ready to use.  The features included were tested on real sites.

The reason MSAccess was chosen as the database was we were moving users from sites that were not accessible to each other over the wire.  It is primarily the best way we have found to import users into groups.  Importing users is usally a one time task, but maintaining group membership is on-going.

Thanks to everyone for the great comments.  We are actually working on a few more modules that will help pay the rent...

mikez

Any experts can comment on why we could not modify these membership fields? Any problems with the issues mikez brought up? I'd like to see an answer on this as a user import is important to a lot of ppl. I'd like to see this is mikez's new version and so would like someone to provide some expert analysis. Anyone?

userObj.Membership.LastLoginDate
userObj.Membership.CreatedDate

Mikez, possibly you could have an import feature option for those who do public websites who want to port these dates fields and those for Intranets who do not want to break any security policies as you described above?

Thanks,

Jason

Great module Mike.

Works a treat!

ikamiksok wrote:

Any experts can comment on why we could not modify these membership fields? Any problems with the issues mikez brought up? I'd like to see an answer on this as a user import is important to a lot of ppl. I'd like to see this is mikez's new version and so would like someone to provide some expert analysis. Anyone? userObj.Membership.LastLoginDate userObj.Membership.CreatedDate

Looking at the stripped down membership provider supplied by the core team and MS, the CreateUser method of the membership class does not take those parameters as arguments.  The stored procedure that creates the membership profile DOES include those parameters. 

IF (@CreateDate IS NULL)
EXEC dbo.aspnet_GetUtcDate @TimeZoneAdjustment, @CreateDate OUTPUT
ELSE
SELECT @CreateDate = DATEADD(n, -@TimeZoneAdjustment, @CreateDate) -- switch TO UTC time

 The largest overload I see in the object browser is the one below.  I haven't tried it yet, but you may be able to implement the provider and overload it with the other parameters.  If I get time I will test it and see.  I think I am about to help Steve on enhancing the Windows Authentication module (to hopefully get included in the core).  I am sure I will know more as we start working on that.

Public Shared Function CreateUser(ByVal username As String, ByVal password As String, ByVal email As String, ByVal passwordQuestion As String, ByVal passwordAnswer As String, ByVal isApproved As Boolean, ByVal providerUserKey As Object, ByRef status As Microsoft.ScalableHosting.Security.MembershipCreateStatus) As Microsoft.ScalableHosting.Security.MembershipUser

Wallew