After an initial attempt to repair the table with MySQL failed, I tried a few things.  What ended up working was to create a new blog, copy the table structure, then recreate the table.  To save others the hassle, here is the table structure

Warning, table structure may have changed between Wordpress MU versions, this works for WordPress MU 2.8.1:

CREATE TABLE `wp_blogs` (
  `blog_id` bigint(20) NOT NULL AUTO_INCREMENT,
  `site_id` bigint(20) NOT NULL DEFAULT '0',
  `domain` varchar(200) NOT NULL DEFAULT '',
  `path` varchar(100) NOT NULL DEFAULT '',
  `registered` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `last_updated` datetime NOT NULL DEFAULT '0000-00-00 00:00:00',
  `public` tinyint(2) NOT NULL DEFAULT '1',
  `archived` enum('0','1') NOT NULL DEFAULT '0',
  `mature` tinyint(2) NOT NULL DEFAULT '0',
  `spam` tinyint(2) NOT NULL DEFAULT '0',
  `deleted` tinyint(2) NOT NULL DEFAULT '0',
  `lang_id` int(11) NOT NULL DEFAULT '0',
  PRIMARY KEY (`blog_id`),
  KEY `domain` (`domain`(50),`path`(5)),
  KEY `lang_id` (`lang_id`)
) ENGINE=MyISAM AUTO_INCREMENT=2 DEFAULT CHARSET=utf8;

Then insert the data:

INSERT INTO `wp_blogs` VALUES (1,1,'appsguy.com','/',
    '2011-07-22 20:24:57','2011-07-22 20:24:57',1,'0',0,0,0,0);

After reloading the site, the blog came up with the default theme. Since the theme files were intact, I went into the admin, switched the theme then the blog was back to normal.

Here is a link to the Certification info:

http://certification.googleapps.com/

http://google-opensource.blogspot.com/2011/02/use-google-apps-apis-without-writing.html

This allows you to access any of the Apps APIs without having to setup your environment or write scripts. The syntax and overhead in maintaining the user CSV sheet is a little challenging, but still easier than rolling your own scripts

Google has just released a packaged version of all of its End User tutorials, How-To guides, etc.  It should be a good resource in helping your customers or employees get up to speed when making the switch to Google Apps.

• Setup your instance (a few steps involved, not the point of this post)
• Start it running
• Generate a Key Pair
• Download and save to where you want to access your EC2 (I used default.pem)
• View your instance properties and grab the Public DNS Name
• Command line SSH into your instance

ssh -i default.pem ec2-user@[public-dns-name]

Depending on how you saved your key, you may need to change the permissions to 400, or SSH will give an error that the file is too open.

Edit: You can get these steps by checking your instance in the AWS management console, then clicking on Instance Actions -> Connect.  It does give the root user, but if you try to log in as root, you will get an error telling you to use ec2-user.

One thing I will give to them is that I have not yet seen a customer that can live 100% in the cloud yet. Cloud based applications and services are getting better very quickly, but most vendors will still admit that they are not yet at the level of all desktop software, which is why people still buy Microsoft Office. MS is trying to push Office 2010 as a way to collaborate in the cloud, but it still relies heavily on desktop software. If your organization is at the point where desktop software is still necessary, there are cheaper options. One way to leverage both online and offline capabilities would be to use Open Office Extensions:

http://extensions.services.openoffice.org/project/ooo2gd

Open Office Extensions will allow you to connect to Google Docs, collaborate, then download an edit locally for the features that either aren’t available yet or need to be used offline.  Hopefully Google will soon make its recently acquired DocVerse service available, which should make collaborating on existing offline content much simpler.

I’ve added code to add a “send as” address to users in bulk.

Denying remote access to everyone is the easiest to accomplish with SSO. The simple solution is to host it on a corporate intranet, without any remote access. Configuring SSO that can only be accessed internally will effectively lock everyone out of web based services. To be clear, there are some services that do not currently support SSO, like the Talk external client, POP/IMAP, and other non-web based services. POP/IMAP can be disabled at the domain, but some of the others cannot be disabled for remote users without turning them off completely. The way to lock these services down is to not sync passwords into Google Apps. If users do not know their password in Apps, then they cannot authenticate directly.

By controlling who knows their password in Apps, an admin can control who has access remotely. If SSO is only available internally, but you would like to selectively allow users to log in, then the netmask of your organization can be entered into the SSO configurations. If access comes from one of those IP addresses, then SSO will be advertised. If not, then the standard login form for Apps will be displayed. From there, users with their passwords can authenticate.

Another method to selectively control remote access, would be to host SSO in the DMZ and advertise for all IPs. Depending on the IP address that the end user is accessing SSO from, the SSO system could be configured to allow or deny access. Because SSO is flexible, additional factors can be used, like the user+IP or even things like One Time Passwords (OTP).

By using SSO, a domain admin has a lot of options for authentication, including locking access down for remote users.

Since the launch of the Google Apps Marketplace, we have seen some pretty impressive apps added.  There are some very complex tools like:  Manymoon, which is a fully baked project management tool; SlideRocket, a pretty impressive web based presentation tool; Aviary, a web based image editor; and a lot more.

One of the great things about the Marketplace is that a lot of very useful web apps that already existed can easily be integrated with Google Apps.  There are also quite a few apps that are smaller in scope, but are very useful.  One simple, but useful tool that I want to call out is Dito Directory.  Contacts in Google Apps are not very easily browsable.  A user can only browse personal contacts, but not the corporate directory.  I’ve had a chance to work with Dito on a major project recently (they rock, BTW), which is where I first saw their directory.  There are a lot of Shared Contacts tools on the Marketplace, but this one also has an end user interface for browsing.  If you’re in the market for a directory, it’s worth checking out.

Another useful tool I stumbled upon is called Survs, for creating surveys.  Survey tools are never glamorous, but they are incredibly useful.  I use Google Spreadsheets Forms for surveys at least every month, but functionality is still limited.  Survs was easy to configure, it was easy to create a new survey, and it’s definitely prettier than Spreadsheet Forms.

If you’re a domain admin, or just run your own business on Google Apps, the Marketplace is worth a look.