When you create a new Drupal installation two users are created. The first is the obvious admin user with uid 1, which you will use to create your first pieces of content (or, for larger sites, to create the moderation role, assign the necessary permissions and create the moderation users). The second user might be less obvious. It's the virtual anonymous user with uid 0. You will not find it in any user listing, you can not assign any roles to it and you can not log in as the anonymous user. It's important to realize that both users are essential.

There are many efforts being put in preventing the deletion of the admin user since you could easily delete it using the admin interface. Webchick provided a short list of support issues about users that did so and who were unable to administer their site. But surprisingly there are also many things that happen when you have no uid 0, depending on which Drupal version you're using. On Drupal 4.6 and 4.7 you receive various Duplicate entry and Access denied errors while on Drupal 5 and 6 there are issues with rebuilding the user permissions and session information is never saved. This means that any actions that require information from the $_SESSION variable will always fail because upon each page request it is completely empty.

The anonymous user doesn't disappear all by itself of course. The most obvious way is to delete the row for uid 0 from the users table. If you wonder why someone would do this, here is a real life example:

Thinking back to when we first installed Drupal, my boss and I looked at the database and sure enough we though that a user with uid set to zero and no user name and or password was a bug and probably just deleted the row. Now looking back, the bug was actually introduced by us.

The solution here is to create a new "empty" user with uid 0. You might also lose the anyonmous user when exporting and importing the users table due to the auto_increment setting, as described in this support request. If this happens, you will need to manually update the record to set the uid value back to 0.

Earlier this year I wrote a small guide on what to do when you're experiencing character encoding issues after upgrading MySQL to version 4.1 or higher. Now after a large combined effort with JirkaRybka a documentation page is set up in the Troubleshooting FAQ: MySQL 4.0 -> 4.1 migration.

This guide includes background information, a description of several issues when upgrading MySQL and a solution for each problem. You no longer need to manually change update.php (cfr. my earlier guide) since a stand-alone script was written that works for Drupal 4.7, Drupal 5 and Drupal 6! This is very important since Drupal 6 will require you to have MySQL 4.1 or up, if you're using MySQL of course, and this will make upgrading so much easier, saving people a lot of precious time debugging. This documentation and the script are all a combined effort of JirkaRybka, Heine, Acert93 and myself.

You can check the original request by Acert93 to provide more information on this issue and see how this documentation came to be.