Most likely you are reading this because you are frantically trying to figure out how to login into your DotNetNuke portal because you have found yourself locked out. You may have even received a password reminder with a blank password. Having fun yet???

When we were first testing DotNetNuke in the DNN 3 beta days, we had a problem with not being able to login into the host account. I fixed the issue by overwritting the host Password and PasswordSalt fields in aspnet_Membership table. Recently, the same issue arose and I had to do this again. So, I decided to jot down a few notes that I hpe will help you in solving your issue. Read on....

Before I explain, lets check to make sure it is not one of the other issues related to not being able to login.

1. Clear your cache and cookies and retry to login
2. Did you recently upgrade your DotNetNuke site or change the web.config? If so, the passwords are encrypted and stored in the membership provider tables using the machine validation and decryption key strings. They are located in the web.config below the server connection string. You can now thank <insert favorite God> you backed up the DNN installation before upgrading, because you can go back to the old web.config and use the machine keys to upgrade your new web.config file. Look for something like this:
                        
     <add key="MachineValidationKey" value="extremelylongrandomlookingstringofcharacterswouldgoinhere" />
     <add key="MachineDecryptionKey" value="anothersetofextremelylongrandomlookingstringofcharacterswouldgoinhere" />
3. Did you accidentally change the Login page in Admin > Site Settings > Advanced Settings? You can do the following: **NOTE** Make sure you change your PortalID appropriately.                         
   From SQL Server Management Studio or Enterprise Manager, run the following statement:                     
                     
   SELECT TabID, TabName FROM Tabs WHERE (TabName LIKE '%Login%') AND (PortalID = '0')

          Find the Tab?
        If you get a result, and are sure it is the Login page, run the following SQL Statement to update your settings:
          **NOTE** Make sure you have the correct  TabID and PortalID!
          
        Update Portals Set LoginTabID = '123' WHERE (PortalID = '0')
                    
        You should now be directed to the login page of your portal....

          Didn't Find the Tab?
        If you did not get a result to the first query and deleted the Login page, you are screwed...just kidding. John Mitchell's Blog         provides the solution.

None of those work for you? Join the club!

The solution:
Assuming you have more than one account for your portal (some lowly user account will do), run the following SQL:

SELECT     aspnet_Users.UserName, aspnet_Membership.Password, aspnet_Membership.PasswordSalt
FROM         aspnet_Membership INNER JOIN aspnet_Users ON aspnet_Membership.UserId = aspnet_Users.UserId
WHERE     (aspnet_Users.UserName = 'host') OR (aspnet_Users.UserName = 'someusername')


You should now be able to see the Password and PasswordSalt row you need to use to replace your host account Password and PasswordSalt.

UPDATE    aspnet_Membership
SET         Password = 'someusernameencryptedpasswordstring', PasswordSalt = 'someusernameencryptedpasswordsaltstring'
WHERE     UserID = 'youraspnetuseridforhost'

Now, go to the login page and request your password reminder. You should now have the information you need to login into your portal.

Hope that helps!

UPDATE 3/12/2006:

It may be neccessary to change the ApplicationID to match the portal in use.

Working from IIS 4 days to IIS 5 was a huge improvement, but I am constantly amazed with the new IIS 6. There are so many goodies I keep finding that were not in IIS 5 that help with administration and performance. The latest one I discovered a couple of weeks ago and have been playing with is Web Gardens. I'm not talking about web farms here, but the horticulture of worker processes. From my testing, I conclude a little web gardening in IIS will definitely help DotNetNuke performance. So, the nest time your DotNetNuke website is getting pounded with traffic and you start seeing delays in page load time, a few extra worker processes can handle the extra load...read on

Too help with performance, each domain should be in its own Application pool within IIS.

"IIS versions earlier than 6.0 use the ASP.NET process model (Aspnet_wp.exe). Under the ASP.NET process model, each unique application version automatically runs in a separate process at run time. All applications that target the same version of the runtime share the same process (or processes in Web garden mode). However, IIS 6.0 uses the IIS 6.0 process model (w3wp.exe) and introduces a new isolation feature called application pooling. Application pooling allows applications to run together in one or more processes, as long as they share the same pool designation. Applications that are assigned different application pools never run in the same process." - MSDN

To create a pool designation in IIS 6.0

1. Open the IIS management console and expand the local computer by clicking the plus sign.
2. Right-click the Application Pools folder, point to New, and then click Application Pool. The Add New Application Pool dialog box appears.
3. Enter the new pool designation in the Application pool text box, and then click OK.

To assign a pool designation to an ASP.NET application in IIS 6.0

1. Open the IIS management console, expand the local computer by clicking the plus sign, and navigate to the folder that contains the ASP.NET application.
2. Right-click the application and then click Properties. The application's properties dialog box appears.
3. On the Directory tab, select the desired pool designation from the Application Pool list.

Since IIS is running in worker process isolation mode, Web gardens become an option.

"In IIS 6.0 worker process isolation mode, application pools enhance Web site or application reliability by isolating applications and the worker processes that service those applications. For even greater reliability, you can configure an application pool to be supported by multiple worker processes. An application pool that uses more than one worker process is called a Web garden. The worker processes in a Web garden share the requests that arrive for that particular application pool. If a worker process fails, another worker process can continue to process requests." - MSDN

To configure a Web garden by using IIS Manager

1. In IIS Manager, expand the local computer, expand Application Pools, right-click the application pool, and then click Properties.
2. Click the Performance tab, and under Web garden, in the Maximum number of worker processes box, type the number of worker processes that you want to assign to the application pool. (You must type a number greater than 1 for the application pool to become a Web garden.
3. Click OK.

How does this help for performance?

First and foremost, under heavy load (web traffic), a worker process can get tied up with a request. If this happens, there is another worker process available to take the load. Utilizing this has definitely helped during peak traffic times. Also, when traffic is steady, each new connection is passed to a different worker process in the Web Garden, in a round-robin scheme. This smooths out the load, instead of  fighting for resources bound to a worker process.

All for now...I have a garden to tend.

The GetSchedule() timeout error:

Error: Schedule is currently unavailable.
DotNetNuke.Services.Exceptions.ModuleLoadException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. ---> System.Data.SqlClient.SqlException: Timeout expired. The timeout period elapsed prior to completion of the operation or the server is not responding. at System.Data.SqlClient.SqlConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.SqlInternalConnection.OnError(SqlException exception, Boolean breakConnection) at System.Data.SqlClient.TdsParser.ThrowExceptionAndWarning(TdsParserStateObject stateObj) at System.Data.SqlClient.TdsParser.Run(RunBehavior runBehavior, SqlCommand cmdHandler, SqlDataReader dataStream, BulkCopySimpleResultSet bulkCopyHandler, TdsParserStateObject stateObj) at System.Data.SqlClient.SqlDataReader.ConsumeMetaData() at System.Data.SqlClient.SqlDataReader.get_MetaData() at System.Data.SqlClient.SqlCommand.FinishExecuteReader(SqlDataReader ds, RunBehavior runBehavior, String resetOptionsString) at System.Data.SqlClient.SqlCommand.RunExecuteReaderTds(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, Boolean async) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method, DbAsyncResult result) at System.Data.SqlClient.SqlCommand.RunExecuteReader(CommandBehavior cmdBehavior, RunBehavior runBehavior, Boolean returnStream, String method) at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior, String method) at System.Data.SqlClient.SqlCommand.ExecuteReader(CommandBehavior behavior) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteReader(SqlConnection connection, SqlTransaction transaction, CommandType commandType, String commandText, SqlParameter[] commandParameters, SqlConnectionOwnership connectionOwnership) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteReader(String connectionString, CommandType commandType, String commandText, SqlParameter[] commandParameters) at Microsoft.ApplicationBlocks.Data.SqlHelper.ExecuteReader(String connectionString, String spName, Object[] parameterValues) at DotNetNuke.Services.Scheduling.DNNScheduling.SqlDataProvider.GetSchedule() at DotNetNuke.Services.Scheduling.DNNScheduling.SchedulingController.GetSchedule() at DotNetNuke.Services.Scheduling.DNNScheduling.DNNScheduler.GetSchedule() at DotNetNuke.Modules.Admin.Scheduling.ViewSchedule.Page_Load(Object sender, EventArgs e) --- End of inner exception stack trace ---

The temporary fix:

Cleaning out the ScheduleHistory table fixes the problem until it gets too full again...

Delete From ScheduleHistory where ScheduleHistoryID > 1

Make sure you backup your database before executing this SQL statement.

I need to investigate more on how the code for GetSchedule() works and how to cleanup the ScheduleHistory more often. Also, we are working with Microsoft on a different issue, they have voiced concern on the performance of the stored proc GetSchedule. I will post any suggestion here when they surface.

 

Working on the DNN FIND project, I thought I would kick around a few ideas about building "importance" into a URL based on user interaction. In a old pre-DNN project, I simply had a page that processed the link click similar to the way DNN Links Module works by using LinkClick.aspx and parameters for the link information, before redirecting to the site. However, I would prefer a solution that went directly to the site, so that the Back button could be used (pressing Back would go back to the redirect page that sends you forward). Plus, I wanted something that would show the real URL in the window status, without setting it using JavaScript. So, this is what I came up with...

The following script is dynamically generated on the Search Results page to include the searchID (every unique search performed against the database has an ID):

<script>
<!--
function DNNFclk(urlID,curRank){
 if(document.images){
  var u="";
  if (urlID) u="url="+u+"&searchID=123456"+"&rank="+curRank;
  new Image().src="/DNNFindClick.aspx?"+u;}return true;}
//-->
</script>

The HTML for the link in the search results looks like this:
<a href="http://www.venexus.com" onmousedown="return DNNFclk('7890','1')">Venexus</a>

How does it work?

When a user clicks a link in the search results, it fires off a JavaScript to fetch an "image", passing in the ID for the url and search results rank. This "image" is really a page that collects the information from the user. On the page that processes the click, basically the curRank and searchID is used in the algorithm that computes the new URL importance. This allows us to track what the user clicks on in order to update the URL ranking.

I have not had the chance to add this to DNN FIND yet, but it should be a great improvement.

Ideas for DNN FIND:

By also tracking the user session, we could check the timeframe from one click to the next. If the timeframes are too close, we could DECREASE the rank. Close timeframes represent bad search results because the user did not spend any time on the site for the link they clicked.

While working with Microsoft concerning the DNN SQLDataProvider and 64-Bit SQL Server 2005 Issue, it was suggested that there was a performance issue with GetTab. While this does not help the issue we are having, it did help with performance...

"There are some implicit converts happening even though you have explicit converts in the statements"

Current GetTab SQL:

select TabID,
TabOrder,
Tabs.PortalID,
TabName,
IsVisible,
ParentId,
[Level],
DisableLink,
Title,
Description,
KeyWords,
IsDeleted,
'Url'= case when F2.FileName is null then Tabs.Url else F2.Folder + F2.FileName end,
SkinSrc,
ContainerSrc,
TabPath,
StartDate,
EndDate,
'IconFile' = case when Files.FileName is null then Tabs.IconFile else Files.Folder + Files.FileName end,
'HasChildren' = case when exists (select 1 from Tabs T2 where T2.ParentId = Tabs.TabId) then 'true' else 'false' end,
RefreshInterval,
PageHeadText
from   Tabs
left outer join Files on Tabs.IconFile = 'fileid=' + convert(varchar,Files.FileID)
left outer join Files F2 on Tabs.Url = 'fileid=' + convert(varchar,F2.FileID)
where  TabId = @TabId

 

The FIX:

select TabID,
TabOrder,
Tabs.PortalID,
TabName,
IsVisible,
ParentId,
[Level],
DisableLink,
Title,
Description,
KeyWords,
IsDeleted,
'Url'= case when Files.FileName is null then Tabs.Url else files.Folder + Files.FileName end,
SkinSrc,
ContainerSrc,
TabPath,
StartDate,
EndDate,
'IconFile' = case when Files.FileName is null then Tabs.IconFile else Files.Folder + Files.FileName end,
'HasChildren' = case when exists (select 1 from Tabs T2 where T2.ParentId = Tabs.TabId) then 'true' else 'false' end,
RefreshInterval,
PageHeadText
from   Tabs
left outer join Files on Tabs.IconFile = 'fileid=' + convert(nvarchar,Files.FileID)
and Tabs.Url = 'fileid=' + convert(nvarchar,Files.FileID)
where  TabId = @TabId

Running SQLDiag.exe confirmed the modification helped improve performance. More details later...

I'll post this to the DNN Bug Tracker shortly...

Update 1/25/2006:

Now in Bug Tracker: 2404

I made the following post on the DNN Forums, and decided to post it here in case someone reads it here first...

This is all related to: Upgrading DNN from local SQL Server 2000 to Remote SQL Server 2005

We are experiencing an issue with DNN and a 64-Bit SQL Server 2005 database server that seems to be related to the SQLDataProvider. We are currently running a production web server (Server A) that has an instance of SQL Server 2000 running locally. We have a mixture of DNN3 and NON-DNN sites running on Server A. All DNN sites are fast and run smoothly, only experiencing a few issues during peak traffic times regarding the local SQL Server 2000. Previously we had a separate server for our production SQL Server 2000 databases. However, we recently acquired a very fast 64-Bit server that came from Overture.com (Server C) and had to make room in our rack by decommissioning the old database server after moving all databases to Server A. Now, we are in the process of moving all Server A databases to Server C , so we can go back to using Server A as web server only. We have been testing and planning our database move utilizing our development server (Server B).  Our goal is to move ALL Server A databases to Server C.

Server A:
Dell 2850
Dual 3 Ghz Xeons
2 Gb RAM
32-Bit
Windows 2003 Standard Edition
SQL Server 2000

Server B:
Dell 1550
Dual 1 Ghz Pentiums
2 Gb RAM
32-Bit
Windows 2003 Enterprise Edition
SQL Server 2000 Standard Instance
SQL Server 2005 Enterprise Instance

Server C:
Dell 7150
Quad Itanium Processors
12 Gb RAM
64-Bit Windows 2003 Enterprise Edition
64-Bit SQL Server 2005 Enterprise Edition

We began testing the NON-DNN site and DNN site databases against Server B, all with success. We also setup DNN instances on Server B that used Server C as database server. Testing was successful, but all DNN databases tested were less than 100 Mb. We noticed that the DNN sites on Server B that talked to Server C DNN databases were slower, but dismissed it as being on the slower Server B when compared to Server A.

So, after much testing for NON-DNN sites, we moved all NON-DNN databases to Server C. All NON-DNN sites use the SQLOLEDB Provider. Our largest NON-DNN database is over 3.5 Gb. After the move, the site with the largest database experienced great performance/speed improvements. Some larger data transactions were executed in almost half of the time. We were very pleased with the results.

After successful NON-DNN databases move from Server A to Server C, we began moving the DNN databases to Server C.  The first 3 were very small databases. However, the largest of the 3, we noticed a difference in speed. Concerned, but determined to move on, we moved a 2.5 Gb DNN database to Server C and gave it a try... The speed was horrible taking as much as 15-45 seconds to deliver a page. We quickly backed out of the upgrade and began our investigation…

Doing a little research, I dug into the DNN documentation for Data Access and looked at the code to see DNN uses System.Data.SQLClient as the provider. Why would SQLOLEDB be fast and the DNN SQLDataProvider be so dreadfully slow and only when on a 64-Bit server? I really have no desire to change any of the core DNN code to use the System.Data.OleDb as the provider to test and see if there is a difference, so any recommedations and/or suggestions are appreciated. 

I know there are a few issues with 64-Bit SQL Server 2005 tools running slow: You may experience slow performance when you run 32-bit SQL Server tools on 64-bit operating systems. But, this should not be related to the issue since this concerns just the tools, or does it?

I plan on burning a support call to Microsoft, but would like to gain any insight others might have before I make the call.

After working with different http components from my ASP/COM/VB days , I was pleased to find the .Net classes for web request and response in the System.Net namespace. There are lots of goodies in both that would have required lots of extra code in the past, especially for parsing out header responses.

HttpWebResponse Class
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemnethttpwebresponseclasstopic.asp

HttpWebRequest Class
http://msdn.microsoft.com/library/default.asp?url=/library/en-us/cpref/html/frlrfsystemnethttpwebresponseclasstopic.asp

Here is a few snippets of code I pulled out of the DNN FIND Spider to show some of the basics of both classes with comments and ideas for those who may try to use this:

'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

'Create the web request object and pass in a URL to process
Dim webReq As HttpWebRequest = HttpWebRequest.Create(sURLToProcess)

'You can specify your own useragent using the UserAgent property
webReq.UserAgent = g_sUserAgent

'Create the web response object by retrieving the web request response
Dim webResponse As HttpWebResponse = webReq.GetResponse

'Check to make sure we get a 200 status response
If webResponse.StatusCode = HttpStatusCode.OK Then
 'We can grab the content type of the document
 sContentType = webResponse.ContentType.ToString()
 'We can check the size of the document
 lContentLength = webResponse.ContentLength
 'We now know what type of document this is, we could add code to
 'decide what we want to parse or save the data  

'We can stream the data (requires System.IO).
 Dim receiveStream As Stream = webResponse.GetResponseStream()
 'Using the stream instance, we could pipes the response stream to a
 'higher level stream reader with the required encoding format
 Dim encode As Encoding = System.Text.Encoding.GetEncoding("utf-8")
 Dim readStream As New StreamReader(receiveStream, encode)

'From here we can save or parse the data as needed...

Else
'If we did not get a 200 status, we could process the status response and
'return a friendly error message, or just ignore the document
End IF

' Release the resources of the response.
webResponse.Close()

'~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

**PLEASE NOTE** - The above code is just a few snippets of the Spider class for DNN FIND Spider that I jotted down from memory. Make sure you declare your variables as the above is provided just to give you ideas for utilizing and understanding HTTP Web Request and Response classes.

I keep wondering why I waited so long to move to .Net, especially after reviewing some of the old code I had for a web crawler in VB and seeing how much less code that was required to do the same thing. Just thinking about that old code makes me nauseous.

Yesterday, we attempted to move a few DNN installations from using a local SQL Server 2000 database to our new SQL Server 2005 server. First, we have a few non-DNN sites that are from pre-DNN days and are using the SQLOLEDB provider. After moving the largest database of 3.5 Gb, testing the site showed remarkable improvements of speed and performance. On pages with heavy data interaction, some loaded almost twice as fast. We then moved a few of the databases for smaller DNN sites to the new server. These sites were really small and a huge difference in speed could not really be determined without some page execution code being added. Then we tried moving a 2.5 Gb DNN database. The move went smooth, but the speed was horrible!

So, this had me thinking about incoming tabular data stream (TDS) remote procedure call (RPC) protocol stream is incorrect error again. Could an issue with the default provider for DNN and SQL Server 2005 be causing trouble? Oddly enough, when monitoring the remote SQL server, there was a huge spike on all 4 processors while processing the page. Well, I am going to find out tonight. I am going to test speed from a remote SQL Server 2000 server and see if there is any difference in speed. I'll post my results here...

UPDATE:

What a surprise. Checkout the results...

 

 

So, it looks like this is a 64 Bit and default DNN data provider issue. As I mentioned above, the old non-DNN sites using SQLOLEDB for the provider were super fast.

Could this be related: You may experience slow performance when you run 32-bit SQL Server tools on 64-bit operating systems

Look like a call to MS Support is in order. I just need to do a little more reseach on the DNN data provider. More details coming soon....

Update 1/4/2005:

After looking through the DNN documentation, I found the following: DotNetNuke Data Access.pdf (428.91 KB)

Let’s recap the 2005 year of DotNetNuke and Venexus.