As I posted previously, this was going to be a longer post. But it got erased because I clicked the wrong button on my mouse, so you all get the Cliffs Notes version. But that's ok, you're a clever group. All three of you. :)

ASP.NET 2.0 Membership

As you may know, ASP.NET 2.0 comes with ASP.NET 2.0 Application Services, a motley gang of controls and APIs that offer basic building blocks for whipping together sophistication web sites with almost no code at all. For example, let's say you wanted to create a web site that required users to register and log in before accessing certain portions, and be able to have different types of users who could access different areas, and even store personalized information about those users. In the past you'd have to code it all yourself, but not any more. There are a series of APIs that you can access and web controls that work against those APIs. For example,

• Membership -- stores usernames, passwords, and handles credentials
• Roles -- groups users in roles
• Profiles -- lets you store specific information (e.g. favorite color) for users
• Personalization -- works with Web Parts to customize web controls so users can have their own, personalized web pages (think My Yahoo)

One nice thing is the APIs are simply interfaces to the data -- they don't deal with storing it. Instead, data is persisted via various providers that communicate with the APIs. So you could choose to have the Membership API work with a Membership Provider called XMLMembershipProvider that knew how to store membership data in an XML file. You could then change your mind and switch to using a provider called MySQLMembershipProvider that stored data in a MySQL Database, and you wouldn't need to change any code. Think of the APIs as object oriented interfaces, and the providers as implementations of those interfaces.

So Many Providers, So Little Time

ASP.NET comes with a few built-in providers (SQL Server, SQL Server Express, XML), but there's nothing stopping you from writing your own provider if you want to store the data in a different or proprietary way. You can download Microsoft's Provider Toolkit and have a go. As a bonus, there's a sample Microsoft Access provider for those of you who want to/have to store your information in an Access database.

By default, ASP.NET 2.0 uses a set of providers that store data in a SQL Server Express database located in your web site's App_Data folder. Which is nice in that your site is self-contained and you don't need to have "normal" SQL Server. But it's bad in that SQL Server Express is kinda wimply, many hosting providers don't support it, and it complicates xcopy deployment because the last thing you want to do is copy your development usernames on top of the production set.

If you have SQL Server Standard/Express 2000/2005 available, you may as well use it as the provider. Here's how.

Configure Your SQL Server for Application Services

First you'll need to install some stored procedures and tables in whatever SQL Server database you plan on using. Thankfully, there's a tool that makes this easy. Navigate to C:\Windows\Microsoft.NET\Framework\2.0.<latest> and run aspnet_regsql.exe. Perform the following steps:

• Click Next.
• Check "Configure SQL Server for application services" and click Next.
• Connect to your database server and choose your database from the dropdown. The database you choose will have some tables and procs added for membership et al. Click Next.
• Click Next to confirm.
• Wait a bit, and you're done. Click Finish.

If you can't or won't run aspnet_regsql.exe (e.g. your company policies require database changes to be in scripts), there are a number of "Install" .sql files that you or your DBA can run. InstallCommon.sql will need to be run first, and you'll need to change the @dbname variable at the top of each script.

Either way, once the database is configured, you can take a look at what got added -- you'll see a number of databases starting with aspnet_ that will contain the membership information.

Add a SQL Server Provider to Your web.config

Next you want to have ASP.NET use that SQL Server database instead of the Express database.

ASP.NET normally accesses the SQL Server Express database via a provider named "LocalSqlServer," and Scott Guthrie posted a tip on renaming that provider so that it instead points to whatever SQL Server database you want. I don't like doing that because a) it's tricking ASP.NET, and b) you run the risk of confusing people by having a provider named "LocalSqlServer" point to something that may not be local. But, it's easy to do if you want to -- just add the following lines to your web.config's <connectionStrings> section:

<remove name="LocalSqlServer" />
<add name="LocalSqlServer" connectionString="YOUR CONNECTION STRING" providerName="System.Data.SqlClient"/>

Anyhow, we're not going to do that. We're going to add explicit lines for our SQL Server database. First ensure there's a connection string in your web.config for your Sql Server.

    <connectionStrings>
        <add name="myConnectionString" connectionString="Data Source=myserver;Initial Catalog=mydatavase;Persist Security Info=True;User ID=myuser;Password=mypassword" providerName="System.Data.SqlClient"/>
    </connectionStrings>

Next, add a Membership section and provider to your web.config's <system.web> section:

<membership>
   <providers>
   <add 
      name="MySqlServerMembershipAuthentication"
      connectionStringName="myConnectionString" 
      applicationName="/MyApplication"
      description="This is a test database" 
      requiresUniqueEmail="false"
      enablePasswordRetrieval="false" 
      enablePasswordReset="true" 
      requiresQuestionAndAnswer="false"
      passwordFormat="Hashed" 
      minRequiredPasswordLength="4" 
      minRequiredNonalphanumericCharacters="0"
      type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.3500.0, Culture=neutral, 
         PublicKeyToken=b03f5f7f11d50a3a" />
   </providers>
</membership>

Use the right connectionStringName for your database, and give it a name you like. The applicationName attribute doesn't have to be your virtual directory, but it should be unique to your application. This allows different applications to have users with the same name in the same database without colliding. You can read more about the attributes on MSDN, but remember that if you choose Encrypted for passwordFormat, you should include your own validation and decryption keys in your web.config like I blogged about previously on passwordFormat.

Lastly, if you plan on having user roles (Admins, Members, Serfs, etc) add a roleManager section to the <system.web> section:

<roleManager enabled="true">
<providers>
<add name="MySqlServerRoleManagerProvider" connectionStringName="myConnectionString" applicationName="/MyApplication"
type="System.Web.Security.SqlRoleProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
</providers>
</roleManager>

Tell ASP.NET to Use Your New Providers

Now let's configure ASP.NET to use the new providers you specified. In Visual Studio, click Website->ASP.NET Configuration from the menu. You'll see the ASP.NET Web Site Administration Tool, which allows you to create users and roles, define application settings, and choose providers. Click the Providers tab, then click "Select a different provider or each feature." You should see your new entries there.

Go ahead and select your new providers, and click Test to make sure they're working correctly. If you want to click the other tabs to see what features they offer, go ahead and do so.

Create a User

Let's create a user, just for testing. Click the Security tab. Click Create User, enter some test values (I named my user "test"), and click the Create User button. It'll say whether the user has been successfully created or not. 

Assuming the user was made successfully, close the window, and take a quick look at your web.config file again. You'll see that the attribute defaultProvider has been added to the roleManager and membership tags. You can actually set that value manually in the web.config instead of using the administration tool.

For fun, connect to your SQL Server database again and view the aspnet_Users table. You should see the new user you created. Notice how the user has a unique UserId and ApplicationId, allowing different applications to have their own separate set of users.

 

If you view the aspnet_Applications table you'll see the applicationName you chose in your membership section. The user's password and other information are stored in the aspnet_Membership table. You can poke around a bit more, then delete the user by opening up the Web Site Administration Tool, going to the Security tab, clicking Manage Users, selecting the user and clicking Delete User.

Roles and Controls

Now that you're set up for ASP.NET Membership, you can open up the Administration Tool again to create some Roles and more users and/or you can go ahead and drag Login, LoginView, ChangePassword, etc. controls onto your web forms. You'll find them under the Login section in the Visual Studio toolbox when editing ASPX pages. Most of the Login controls need no code at all -- you can edit their templates, and they'll automatically read the membership information from your web.config and the providers.

Directories in your site can then be protected by creating a web.config inside them and using simple authorization blocks, e.g. inserting

<?xml version="1.0" encoding="utf-8"?>
<configuration>
<system.web>
<authorization>
<allow roles="SomeRole" />
<deny users="*" />
</authorization>
</system.web>
</configuration>

protects a directory from everyone except users in the role "SomeRole."

Conclusion

Well, what started out as a Cliffs Notes got bigger than I expected, but that's OK. Hopefully I've shown you enough to not only free yourself from SQL Server Express, but encourage some of you to dive into the ASP.NET Membership system.

So I have a little rant ... I was typing up a blog article on ASP.NET Membership Providers and how to move that information from SQL Server Express to SQL Server 2005 Standard. And I accidentally (as I sometimes do) clicked the thumb button on my Logitech MX510. By default that button executes the browser's "back" button, but in the case of blogging, instead executes the "undo" feature of the textbox you're typing into. Which means my pages of text disappeared, and of course there's no way to "re-do" the text other than typing it all in again.

So I'm a bit annoyed. And in order to not have that happen, I have to go to logitech.com, download the software, install it, allow the inevitable reboot, then open the software, disable that button, then have the software run in my tray all the time.

So...I'll be back later.

I'm currently working on a property tax consulting startup, and I was noticing that some queries were running slowly. I'm familiar with database indexing, but I wanted to see what the new Database Tuning Advisor that comes with SQL Server 2005 could come up with. It supposedly helps database newbs tune their database without having to know how to create indexes, etc. Seasoned DBAs will probably gasp in horror (with good reason) at automated tuning processes, but what the heck...let's take her for a spin.

Don't Start Without a Trace

The first thing you want to do is create a trace file containing the SQL statements you want analyzed. So fire up SQL Server Profiler, click File->New Trace, and connect to your database. In the trace properties screen you'll want to use the Tuning template, click Save to File, choose a filename, check Server processes trace data, and click Run. See the screenshot below for details.

Now you need to execute the SQL statements that are running slowly. In my case, I just run through a number of test cases in my web application, ensuring realistic database calls. But you could also run SQL statements directly from Query Analyzer or SQL Server Management Studio. You'll need to ensure that your database command timeout is set high enough so your queries finish running instead of rolling back.

Once the SQL statements have finished, stop the trace and exit SQL Server Profiler. You now have a trace file containing all the SQL statements you want tuned. It's a binary file, so don't bother reading it in Notepad, although you can open it up and view it using the Profiler.

Generate Database Tuning Recommendations

Now it's time to tune your database by starting a new Session in the Database Engine Tuning Advisor (DTA -- don't ask why the E is dropped). The DTA groups its recommendations into Sessions. Each session starts out with a Workload (a list of SQL statements to evaluate, e.g. from your trace file) and a set of databases & tables to tune. A Session can either be used to generate tuning recommendations (e.g. Indexes, Statistics, etc), or evaluate pre-specified recommendations and let you know how well they work.

So, open up the DTA -- it'll start making a new Session for you automatically. Connect to your database, select the trace file, choose the database to be tuned from the database dropdown, and put checkboxes next to the databases/tables you want to tune. I didn't bother with the Tuning Options tab, but you can take a look out of curiosity.

Now click Start Analysis at the top, and wait a bit. The Tuning Advisor will run the SQL statements from the trace file, think a bit, and then spit out some recommendations. In my case (see below) it recommended some indexes and recomputing some statistics. It also gave a guesstimate on the speed improvement.

Using the Recommendations

Now you have a set of recommendations, and you have a few choices under the Actions menu item. You can Save Recommendations, which will generate a .sql script file you can apply to your database. You can Apply Recommendations, which just means the Tuning Advisor will apply them to your database, either now or at a specific time (like 2am) in the future. You can also Evaluate Recommendations, allowing you to try them out & see how much they improve performance, without permanently affecting your database. Before Saving, Applying, or Evaluating, you can uncheck any recommendations you want to skip.

I decided to evaluate the recommendations, which creates a new Session (11:32:46 AM) displayed a screen like the one below. Note how the tabs on the top allow you to switch between various Sessions. The tab on the left (the one from 11:08:53 AM) is the first Session that generated the recommendations.

Now that we've set up a "what-if" Session, go ahead and click Start Analysis again, and a Progress screen will come up. The Tuning Advisor will apply the changes, run some comparison tests, undo the changes, and display the results. In the reports tab, you can view reports like Statement detail report (see below) to see how much faster your queries are executing. You can also see how much disk space the indexes take up, and other information.

If you're happy with the results, you can go ahead and Save or Apply the recommendations.

But let's say that you want to try some of the recommendations but not others. If so, you can go back to the original set of recommendations (click its tab, or double click it in the Session Monitor window on the left), check/uncheck some recommendations you want to try, and Evaluate Recommendations again. The ability to play with different sets of recommendations and evaluate them without permanently affecting your database is handy and powerful.

Once I had a set of recommendations whose results I liked, I applied them to my database. I then fired up my application and run through a few test cases, and it ran much faster (as I suspected).

Final Thoughts

The SQL Server Database Tuning Advisor is a nice tool. It probably won't out-tune a skilled DBA, but it does a decent job in recommending indexes. I also like the ability to try "what if" scenarios to evaluate different indexes.

I had a few beefs, however. I didn't like the default names of the recommended indexes, but there was no way to edit them in the GUI. Similarly, there's no way to use the DTA to evaluate your own recommendations -- you can only evaluate recommendations that the DTA comes up with*.

Overall, though, it was a fun tool, and easy to use.

 

* - you can actually use the DTA with custom recommendations (i.e. ones that you came up with) by editing XML files and importing them into the DTA using a command line tool. You can also edit existing DTA recommendations by exporting them to XML, editing them, and re-importing them. I think that's pretty lame that you can't use the GUI for it, but oh well.

I was dealing with an ASP.NET SqlDataSource query that kept timing out, which was annoying because I was trying to run my application through the Database Tuning Advisor (a SQL Server 2005 tool that analyzes trace logs and recommends indexes). The timeouts were preventing me from getting through my whole test case, though.

So, I found a quick solution to setting the timeout value for a SqlDataSource: add a Selecting event handler and put

protected void mySqlDataSource_Selecting(object sender, SqlDataSourceSelectingEventArgs e)
{
e.Command.Command = 300; // 5 min timeout
}

Easy peasy. :)

So I happen to love edit & continue in C# with Visual Studio 2005. There are people who say it encourages sloppy programming (which is true), but for me, there are some things I just can't code as effectively unless I know the runtime state. For example, writing complicated regular expressions against the results of various database queries and algorithms. Do I know if the regular expressions will work exactly before I run the code? No. Do I know if the code will work for all data permutations, beforehand? No.

Hence, edit & continue's blessing. Fire away, hit your asserts or whatnot, and if things look wrong, adjust on the fly. Now, I don't suggest doing big code restructuring while in edit & continue (could get messy & hard to manage), but you are able to if you need to.

Anyhow, much to my dismay I noticed that Edit & Continue stopped working after a while. I couldn't figure out what the deal was, since I was always getting "Changes are not allowed when the debugger has been attached to an already running process or the code being debugged is optimized" whenever I tried to edit the code while debugging. I also noticed that not all my variables were showing up in the Locals & Auto debug windows (this is a hint for the punch line).

Michael Freidgeim has a nice workaround if you get stuck and my simple solution doesn't help you.

His post didn't help, and it took me a few minutes to realize that my project was in "Release" mode instead of "Debug." Whooooops! I guess I didn't notice that because I was able to mostly debug, even in release mode. But I shoulda caught that. Anyhow, flipping back to Debug mode fixed the issue.

So after upgrading my XP Pro laptop to 2GB of RAM, I'm no longer able to hibernate it. Which stinks. I instead get the helpful "Insufficient System Resources Exist to Complete the API" error. And no, having lots of free disk space doesn't do anything.

Apparently it's a known issue, with an unsupported hotfix that you have to get by calling Microsoft. Thankfully, Owen Cutajar's UGH post contains a link to download the fix. Let's see if it works...

Edit: Seems to work! :)

I was looking into ways to easily back up my local SQL Server database from the command line, and copy the resulting backup to my fileserver. That way I could kick off a backup manually or from a scheduled task. There are a few articles out there but they're more specific to SQL 2000 or earlier. Here's how to do it for SQL Server 2005.

I first made directory c:\sqlbackup and added a SQL script called backup.sql:

BACKUP DATABASE streamline TO DISK = 'c:\sqlbackup\streamline.bak' WITH INIT
GO
BACKUP LOG streamline TO DISK = 'c:\sqlbackup\streamline_log.bak' WITH INIT
GO

The above commands simply create log & database backups of the "streamline" database. I used the INIT parameter so that the backup files only create one version of the database (otherwise the backup files will grow & grow, containing every version of the database, each time you run a BACKUP command).

Then I made a simple batch file called backup.bat:

@echo off 
REM get today's date and time as one big string
for /f "tokens=2-4 delims=/ " %%i in ( 'date /t') do set theday=%%k%%i%%j
for /f "tokens=1-2 delims=: " %%i in ( 'time /t') do set thetime=%%i%%j
set now=%theday%%thetime%

REM create backup files
C:
cd "\Program Files\Microsoft SQL Server\MSSQL.1\MSSQL\Binn"
sqlcmd -S localhost -U sa -P somepassword -i c:\sqlbackup\backup.sql -o c:\sqlbackup\log.txt

REM copy backup files to backup device
xcopy "C:\sqlbackup\*.*" \\10.1.10.50\ben_backup\sqlbackup\%now%\ /E /H /R 

The first section uses some DOS batch trickery to create a variable called %now% that contains the current day and time in the form of yyyymmddhhmm. The second section runs the backup script & writes the output to c:\sqlbackup\log.txt. The last section copies the all the backup files to my fileserver, inside a date & time specific folder. Notice how I used the %now% variable in the xcopy destination parameter.

Now my backup folder contains timestamped folders containing everything I need to restore my "streamline" database. You can use a similar technique to make file backups.

The problem

When the number of computers in your house starts to grow, a file server starts looking more attractive. A place to back up all your important files, as well as store central files (e.g. virtual machines, tools, photos, mp3s) that are used by multiple machines. Sure, you can burn em to CD or DVD, but that's so slow, manual, and old school. Where exactly can you back up those files?

Option 1: Get a DAS (Direct Attached Storage)

AKA an external USB drive. USB enclosures are easy to get, and you can definitely store a lot of files on them. I have a few lying around, and you don't even need an external power brick for the 2.5" drive enclosures. I decided against them, though, since I needed to share files between multiple computers. 

Advantages:

• Cheap
• Very quick & easy to use
• High transfer speed

Disadvantages:

• Can't share files to multiple computers at the same time
• Connecting to a different client involves unplugging, lugging, & plugging.

Option 2: Build a File Server

You could also build a full-fledged file server. Get a no-frills computer, load Linux or Windows on it, stick a bunch of drives in there, and share them across the LAN. I decided against this option for the time being since I wanted something cheap, easy, small, & quiet.

Advantages:

• A file server can be used for other things, like a print server, mail server, web server, etc. Which can be fun, a source of geek pride, and educational.
• Administration is via the server GUI, which you probably already know very well. And if you don't, it helps you build your resume. "Familiar with Windows Server administration" looks better than "Familiar with ECS EZ-NAS 2000."
• Very good hardware support, including gigabit LAN
• Support for RAID (software or hardware), so you can mirror two drives in case one fails
• Advanced features like disk quotas, permissions, etc. You could also set up a WebDAV or FTP server to be able to access your files over the internet.

Disadvantages:

• Cost: running a full OS (especially Windows 2003 or a fancy Linux GUI) can require more powerful hardware, meaning more money. More powerful machines also use more power.
• Size: a normal server can be kinda bulky.
• Time: installing & configuring an OS can take a while. It's not awful, but time is money!
• Noise: a full server can be noisy, too, unless you spend more money making it quiet.

Option 3: Get a SAN (Storage Area Network)

I'm not really considering this due to the cost, although you can create a SAN using a file server (above) that implements iSCSI. There is a good (albiet a bit older) walkthrough for Linux and Windows here and of course Wikipedia has plenty of blurbage on it.

Option 4: Store Files Online

You could FTP all your important files to your ISP's server (or your server), or use your Gmail account like a hard drive, or use an online storage provider like Web 2.0 darling Box.net, collaboration tool Basecamp, or others. I use this method for sharing files with others, as offsite backup, and before travelling, but not as my main file storage.

Advantages:

• No local equipment needed. You don't need to deal with hardware at all, which is attractive.
• Cheap, even free for smaller amounts of files. Like if you're just backing up source code, documents, etc.
• Access from anywhere, even on the road. If you have a net connection, you've got your file.
• Reliable: in theory your ISP, Gmail, Basecamp, etc will have better backup & power systems than you do. So you don't need to worry (as much) about your files getting destroyed due to fire, hardware failure, etc.

Disavantages:

• Slow, oh how slow. Basically as slow as your internet connection, which is probably 99% slower than your LAN. Which rules out videos and large files.
• Not a lot of storage. This is relative, of course. 1-5gb might be plenty for some people, but not for others. Upgrading to more storage might either be expensive or not an option.
• Out of your control. If the provider goes south, your files have, too.

Option 5: Get a NAS (Network Attached Storage)

This is the option I'm trying out. A NAS is basically external storage that you connect to your LAN. Your computers then access it over the network. You can always buy an enclosure for about $100 from NewEgg, etc (search on NAS), but I recently stumbled across NASLite and FreeNAS, embedded Linux kernels that turn an old PC (e.g. 200mhz!) into a NAS. Here is a very good and recent walkthough on FreeNAS, and here is a review on NASLite (plus a tip on making a 1.7mb floppy in order to boot NASLite). I'll post an update once I have either FreeNAS or NASLite running.

Advantages:

• Inexpensive, especially if you already have an old PC lying around. If you don't, you can always buy one from the Salvation Army, Craigslist, or vendors like RetroBox.
• Quiet: Old PCs don't need a lot of fans, and can often get away with passive cooling. The NAS units you buy are also pretty quiet.
• Size: Old PCs aren't small, but the dedicated devices are. And some of them are even cute, leading to a better WAF.
• Easy: Easy enough to get going.
• Stability: A simpler device means fewer moving parts, as well as very little (if any) risk of that server getting infected with trojans and viruses. That doesn't mean that an infected client can't stick a virus-laden file onto the NAS, though, so make sure all your client PCs have antivirus (hint: Google Pack has a free 6-month Norton Antivirus).

Disadvantages:

• Transfer speed: you're limited by the speed of your network and the amount of memory in the server. If you're running gigabit LAN, then it's decent, but if you're 100mbit or 10mbit, you'll start to notice transfer times for larger files compared to USB or Firewire. You can still stream mp3s & copy files around, but streaming video might be an issue for slower networks.
• Size: Old PCs can be big.
• Features: Cheaper NAS solutions don't offer RAID, which means if you lose the drive, your files are gone. FreeNAS does offer RAID, though, which is why I'm trying it first.

Conclusion

Hopefully the above helps you when considering storage solutions for your home network and important files. Keep an eye on DevelopmentNow for an update after my adventure with FreeNAS on a celeron 600.

A few weeks back I blogged about using UltraVNC for remote support. Since then I've used it a few times to troubleshoot problems for clients in Arizona, Chicago, etc and it works great. A picture truly is worth 1000 words. No more dialogues that go like this:

Client: I'm getting an error with the system.
Developer: What error message are you getting?
Client: I don't know, it's just blank.
Developer: Which part of the screen is blank?
Client: The system is blank, like I just said.
Developer: Hmm. Ok...can you send me a screenshot?
Client: How do I do that?
[5 minutes of screenshot tutorials go by, ending with the developer getting several blank emails but no actual screenshots]
Developer: Well, let's skip the screenshot for now. Can you go to the page with the error and copy and paste it into an email for me?
Client: Ok, here goes.
[a few minutes later, a blank email arrives in the developer's inbox]
Developer: That didn't come through, can you try selecting more of the system and pasting it into an email for me?
Client: *sigh* Ok, I'll try again. Here it comes.
[a few minutes later, an email containing the system's URL arrives in the developer's inbox]
Developer: Hmm. Can you just copy and paste the entire browser window into an email?
Client: Isn't that what I just did?

...and so on, ending in a frustrated client, an exasperated developer, a broken system, and world suffering. Of course, the issue will turn out to be an empty dropdown or something, which you could have found out in 10 seconds if you could actually see the client's computer screen.

So, if you have remote clients whose desktops you need to see for troubleshooting, software installation, diagnostics, & whatnot but you're too cheap to pay for WebEx, et al. you should check out UltraVNC SingleClick. I had some instructions in my previous blog post, but let me know if you want me to put up a step-by-step tutorial on setting it up.

ASP.NET 2.0's new membership provider allows for three different ways to protect user's passwords via the passwordFormat attribute:

• Clear: passwords are stored in clear text. Fine for non-sensitive applications.
• Encrypted: passwords are encrypted. Note that you will have to put a hard-coded decryption key in the <machineKey> tag in your web.config or machine.config. Otherwise you'll get a "You must specify a non-autogenerated machine key to store passwords in the encrypted format" error when trying to create users. To create a machineKey tag with a set of random tags, you can use my machineKey generator (source code included).
• Hashed: passwords are not stored in the database at all, only an SHA-1 hash. This means passwords can not be retrieved at all -- if a user forgets their password, they'll have to request a new, randomly-generated one.

Below is an example of a <membership> tag using the Encrypted password format.

        <membership defaultProvider="MySqlMembershipProvider" >
            <providers>
                <add name="MySqlMembershipProvider"
                connectionStringName="MyLocalSQLServer"
                applicationName="MyAppName"
                                 requiresUniqueEmail="false" enablePasswordRetrieval="true"
                                 enablePasswordReset="true" requiresQuestionAndAnswer="false"
                                 passwordFormat="Encrypted"
                                 minRequiredPasswordLength="4"
                                 minRequiredNonalphanumericCharacters="0"
                type="System.Web.Security.SqlMembershipProvider, System.Web, Version=2.0.0.0, Culture=neutral, PublicKeyToken=b03f5f7f11d50a3a" />
            </providers>
        </membership>

I made some updates to the machineKey generation program I mentioned in my machineKey generation post. It now returns a complete machineKey tag for ASP.NET 1.1 or 2.0 that you can copy and paste into your web.config or machine.config. You can run the generator or download the code here.

Robert Scoble, blogger-under-notice from Microsoft, posted an interesting blurb about search ranking and secret blogger cliques. He suggested sticking the word brrreeeport in your blog to prove his point about tagging on Technorati.