Note: I'm assuming VB works the same as C# here. I'd be surprised if they differed on this.
If you leave it there (and don't have a static constructor), it will depend on the version of .NET you're using. It's only guaranteed to be run "at some point before the first reference to a static field". You can even create instances and the type initializer may not run! If you have a static constructor (even an empty one), the type initializer will be run directly before the first reference to any constructor or any static member. (Basically, almost anything you actually do with it will initialize it.)
The actual observed behaviour has become lazier in .NET 4 compared with .NET 3.5, as I blogged about. Note that this is only talking about the desktop framework; I don't know what Silverlight or the Compact Framework do.
If the method can throw an exception, I'd be tempted to do it rather more lazily in the first place, in a method call, maybe caching the result appropriately. That way, the method can let the exception bubble up and the caller can try again later. That's appropriate if it's a potentially transient exception you're considering. If it's something which indicates the whole system is unusable, it's fine to let the type initializer fail.