I've fought with this before, and am getting it again on a fresh SBS R2 install in monitoring reports (and the Event Viewer/System log):

The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {E579AB5F-1CC4-44B4-BED9-DE0991FF0623} to the user NT AUTHORITY/NETWORK SERVICE SID (S-1-5-20). This security permission can be modified using the Component Services administrative tool.

It took a long time to track down/fix the first time.  It was faster this time, but I'm documenting it now for future reference.  I underlined the important bits above.

First connect the dots:

1. Looked up that CLSID with regedit in HKCR\CLSDID\{E579AB5F-1CC4-44B4-BED9-DE0991FF0623}
2. Looked up its AppID there: {56BE716B-2F76-4dfa-8702-67AE10044F0B}
3. Open Component Services: Start > Run > dcomcnfg
4. (Guess that it's VSS related since SBS often has VSS errors, and) open My Computer > DCOM Config > Volume Shadow Copy Service > properties dialog.
5. Confirm Volume Shadow Copy Service has that Application ID: {56BE716B-2F76-4dfa-8702-67AE10044F0B}

Then actually make the fix:

1. Open Security tab > Launch and Activation Permissions > [Edit] button
2. [Add] Network Service,  [OK]
3. Allow Local Activation permissions to Network Service,  [OK], [OK]

My opinion: connecting the dots shouldn't be so nearly much more involved than making the fix.

(Credit to this article for documenting the basic troubleshooting process.)

I've been using Vista Business for about a year.  I've had it on a secondary work machine since around May, and as my primary work machine since November. Overall, it's quite nice.

But it's definitely had its quirks, mostly with waking from standby or hibernation. I put a couple hotfixes on, and they definitely helped, but it still did have an occasional strangeness. That said, in almost a year's time, I only remember needing to hard-reset it perhaps 3 times, and needing to reboot it maybe 5.

Now, I think that's great, considering these machines belong to a tweaker like me (read: not a grandma or Mac-type user who doesn't try new things).  I'd say it's comparable reliability to a current stable XP system. This is an important comparison -- XP has been maturing since 2001, but Vista started out at the same level of reliability.

As an aside, I've had several non-technical folks ask me "is Vista as bad as they say?" and I've only been able to respond "as who says?"  The only negative reviews I've seen were some journalists who must have put Vista on old hardware without current drivers.  But IT professionals I've talked to who've used Vista for a while seem to like it.

So anyway, I still didn't want that occasional quirk, so I tracked down hot-off-the-presses Service Pack 1, and applied it last night.  It took about 45 minutes, and went flawlessly.  Hooray for that, and hopefully it sails even smoother now...

For those in a similar tight place...

Alright, I shouldn't have experimented with the BIOS settings so flippantly, but all my other current hardware either has an internal "reset" jumper, or it automatically detects problems and resets itself, so I assumedI was safe...

Well imagine my surprise that powering on gave me an utterly blank screen, and no combination of keys would fix it.  Opening the case showed no reset mechanism either.  And Sager's website showed no support options except an RMA form...

Fortunately I found (elsewhere) an email address for support: websupport@sagernotebook.com.  I emailed and got a response within 24 hours asking for a serial number.  Knowing it was out of warranty (and expecting a "sorry about your luck" response), I gritted my teeth & answered.

Glory be, 12 hours later I received these instructions from Daniel on how to reset the BIOS to factory settings:

Bob,

If you feel comfortable, Try this, 1st unplug all the power remove the AC Adapter and the Battery. And open the bottom cover(see attachment picture) and unplug the Cmos-Battery’s wire(red&black crop by Green Color) for like 15sec. Then reconnect it back the wire then everything ACA and the Big Battery. See that will help.

*** We don't hold any responsibility ***

Daniel
Sager computer
18005 Cortney Ct
City of Industry, CA 91748
Tel# 1-800-741-2219 626 964 4849
Fax# 626-964-2381

Despite Bob-ifying me, it made enough sense that I was booting normally in 5 minutes (and mostly time for the tiny screws).

It's good info, Sager just needs to share it more easily.  I wrote back to thank Daniel, and suggested they put this kind of info in a public knowledgebase.

Windows XP Professional?  Check.

But what about 64-bit?  Apparently it's actually not supported on 64-bit Windows XP Professional.

1. Comments were probably lost.  Sorry.  I noticed spammers were usually changing the subject from the default "re: whatever", so I killed most of the rest. 
   
2. Search is gone for the moment.  I'll add it back in Real Soon Now.
3. Images and other locally-hosted junk is probably all broken.  I'll fix that slightly sooner.
4. Comments are screwy (dotText saved as HTML.  dasBlog doesn't.)
5. Layout is messed in IE6.
   

I upgraded another client's SBS 2003 machine to SP1 this past weekend.  It went remarkably smoothly, but we forgot to check their smartphones' access to Exchange til today.  No connection, we checked the /OMA virtual directory, and got this error:

"A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator."

Much "jiggling" (yknow, rerunning wizards, regenerating the web certificate, etc), and googling got me no answer.  I did see this error in the Application Log, though:

An unknown error occurred while processing the current request:
Message: The remote server returned an error: (403) Forbidden.
Source: Microsoft.Exchange.OMA.ExchangeDataProvider
Stack trace:
   at Microsoft.Exchange.OMA.ExchangeDataProvider.OmaWebRequest.GetRequestStream()
   at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices.GetSpecialFolders()
   at Microsoft.Exchange.OMA.ExchangeDataProvider.ExchangeServices..ctor(UserInfo user)

Message: Exception has been thrown by the target of an invocation.
Source: mscorlib
Stack trace:
   at System.Reflection.RuntimeConstructorInfo.InternalInvoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture, Boolean isBinderDefault)
   at System.Reflection.RuntimeConstructorInfo.Invoke(BindingFlags invokeAttr, Binder binder, Object[] parameters, CultureInfo culture)
   at System.RuntimeType.CreateInstanceImpl(BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at System.Activator.CreateInstance(Type type, BindingFlags bindingAttr, Binder binder, Object[] args, CultureInfo culture, Object[] activationAttributes)
   at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)

Message: Exception of type Microsoft.Exchange.OMA.DataProviderInterface.ProviderException was thrown.
EventMessage: 
UserMessage: A System error has occurred while processing your request. Please try again. If the problem persists, contact your administrator.
Source: Microsoft.Exchange.OMA.UserInterface
Stack trace:
   at Microsoft.Exchange.OMA.UserInterface.Global.Session_Start(Object sender, EventArgs e)
   at System.Web.SessionState.SessionStateModule.RaiseOnStart(EventArgs e)
   at System.Web.SessionState.SessionStateModule.CompleteAcquireState()
   at System.Web.SessionState.SessionStateModule.BeginAcquireState(Object source, EventArgs e, AsyncCallback cb, Object extraData)
   at System.Web.AsyncEventExecutionStep.System.Web.HttpApplication+IExecutionStep.Execute()
   at System.Web.HttpApplication.ExecuteStep(IExecutionStep step, Boolean& completedSynchronously)


For more information, see Help and Support Center at http://go.microsoft.com/fwlink/events.asp. 

What a mess.  But I recognized that "(403) Forbidden" as a web server error (although not on the actual OMA directory).  Combining that with info from similar OMA issues, I checked the /exchange-oma virtual directory's settings, and aha! it was denying access to all IP addresses except 127.0.0.1 and one we don't use.  It was not making an exception for the primary local address.  So I added that and all's now good.

So when you're having OMA problems, try the usual stuff (including checking the OMA virtual directory), then also check settings on the exchange-oma virtual directory.

Lesson learned.

related docs:
• http://www.eggheadcafe.com/ng/microsoft.public.exchange.mobility/post612531.asp
• http://support.microsoft.com/kb/817379
• http://support.microsoft.com/kb/898131
• http://support.microsoft.com/kb/883380