After going through the steps of removing GUIDs from the default SharePoint 2010 databases, I noticed a whole lot of Event Log critical errors listed against the SharePoint Foundation source column. Specifically, these errors would refer to the old database name of the Content DB for Central Admin.
The Event log errors would look something like this:
SQL Database 'SharePoint_AdminContent_28d23664-bca8-4408-99dc-12fe65cd3f96' on SQL Server instance 'xxx' not found. Additional error information from SQL Server is included below.
Cannot open database "SharePoint_AdminContent_28d23664-bca8-4408-99dc-12fe65cd3f96" requested by the login. The login failed.
Login failed for user 'yyy'.
After performing the steps (e.g. what's listed in this blog post by Dirk Van den Berghe) to change the Central Admin's content db name (aka. SharePoint_AdminContent_[guid]), there seems to be a missing step. After moving the content around and perhaps (if you're brave) deleting the original guid-laden database from your SQL server, there remains references to the original guid-laden name in SharePoint 2010's configuration.
I did some digging around in the Config database itself - I know from previous experience and various articles and blog posts around the web that its a very bad idea to start modifying data in the DB itself, however there is no harm in having a peek inside, to see if we can make sense of the environment.
The most obvious table in the Config db is named [Objects]. Performing a SQL query against this table can show whether there's a reference to the original "AdminContent" db there:
SELECT * FROM [Objects] WHERE Name LIKE '%SharePoint_AdminContent_28d23664-bca8-4408-99dc-12fe65cd3f96%'
And - indeed there is.
To resolve this issue, you can run the Remove-SPContentDatabase Powershell command. In order to run it, you need the internal SharePoint GUID reference for the ContentDatabase. Luckily, this is the same GUID found in the Id column of the [Objects] table in your config db.
The Remove-SPContentDatabase powershell command works even if the database no longer exists or is accessible from the SQL server - it simply plows on through the removal of the reference.
It's worth noting that other blog posts that discuss the removal of GUIDs from the AdminContent DB's name actually do specify that you should perform the Remove-SPContentDatabase powershell command. For example, this post by Todd Klindt. The difference is subtle, but important, particular if like me you like your SharePoint environment to be as clean as possible.