DNN Event ID 1310 after moving website to new server Exception message: Unsecured Passwords Format Detected
IIS throwing Event ID 1310 Exception message: Unsecured Passwords Format Detected
The Error Message
Exception information: Exception type: ConfigurationErrorsException Exception message: Unsecured Passwords Format Detected. The Membership Provider that contains the unsecure passwords format is: AspNetSqlMembershipProvider. The obsoleted password format is: Encrypted. For more information, see https://go.microsoft.com/fwlink/?linkid=834784.
Request information: Request URL: Request path: User host address: User: Is authenticated: False Authentication Type: Thread account name: IIS APPPOOL\DefaultAppPool
The Problem was actually simple and a “user error”
We tried to connect the website up to the wrong database. i.e. When we copied the database and moved it, we inadvertently copied the wrong database. This caused the above error due to the fact that the machinekey data in the web.config file was wrong for the database.
This caused the error 1310 to be thrown and the Application Pool associated with the new incorrectly setup site to stop.
Connect to the correct database!
Further to this we encountered a really weird set of errors after this. Initially the error appears to be a connection issue. But then we started getting failings that would come an go.
Error logs showing plenty of Event ID 1310 but also in the DNN logs:
DotNetNuke.Services.Log.EventLog.DBLoggingProvider – System.Data.SqlClient.SqlException (0x80131904): Could not allocate space for object ‘dbo.EventLog’.’PK_EventLogMaster’ in database ‘bla’ because the ‘PRIMARY’ filegroup is full. Create disk space by deleting unneeded files, dropping objects in the filegroup, adding additional files to the filegroup, or setting autogrowth on for existing files in the filegroup.
at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection, Action`1 wrapCloseInAction)
at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj, Boolean callerHasConnectionLock, Boolean asyncClose)
at System.Data.SqlClient.TdsParser.TryRun(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj, Boolean& dataReady)
at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString, Boolean isInternal, Boolean forDescribeParameterEncryption)
at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async, Int32 timeout, Task& task, Boolean asyncWrite, Boolean inRetry, SqlDataReader ds, Boolean describeParameterEncryptionRequest)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, TaskCompletionSource`1 completion, Int32 timeout, Task& task, Boolean& usedCache, Boolean asyncWrite, Boolean inRetry)
at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method)
at PetaPoco.Database.ExecuteScalar[T](String sql, Object args)
at DotNetNuke.Data.PetaPoco.PetaPocoHelper.ExecuteScalar[T](String connectionString, CommandType type, String sql, Object args)
at DotNetNuke.Data.SqlDataProvider.ExecuteScalar[T](String procedureName, Object commandParameters)
at DotNetNuke.Data.DataProvider.AddLog(String logGUID, String logTypeKey, Int32 logUserID, String logUserName, Int32 logPortalID, String logPortalName, DateTime logCreateDate, String logServerName, String logProperties, Int32 logConfigID, ExceptionInfo exception, Boolean notificationActive)
at DotNetNuke.Services.Log.EventLog.DBLoggingProvider.WriteLog(LogQueueItem logQueueItem)
The issue turned out to be that the database was a legacy database we received from another host. They had defined a database limit size in the SQL database it’s self. This caused the database to strop responding to DNN in a way we had never seen. After some time, the maintenance would drop the size of the database just below the limit and the DNN site would fire up. Until it reached the SQL database limit again.
Not likely to be a problem for many people, but something to check in the SQL dates settings.
The fix update
Increase or remove the size of the SQL database limit.