This post started out as a comment on one of Jamie's recent posts, however, I realised that the explanation would be easier to follow with screenshots... so here we go.
To paraphrase, Jamie's issue was that whilst trying to use an SSIS package he was getting a DCOM access denied error (full details here) - this had worked in previous environments, but not once it got to Production. The eventual solution that got everything working was to make the account running the package a local administrator (as it was in other environments) and reboot the server.
Whilst this obviously got things working, what I'd like to illustrate here is a more secure way of overcoming this type of issue - as a platform guy, developer code running with full admin rights makes me twitchy! 
DCOM security is managed using the 'Component Services' MMC snap-in, a shortcut to which is 'Start -> Run -> DCOMCNFG'
![]()
The next step is locate the component that needs to have its security tweaked. Jamie's post shows how to use the CLSID from the error message to locate the registration information for the component in the Registry.
The value of the ''AppID' key is the surefire way of locating the component in DCOMCNFG, however, this is only visible from the component's property page - so ideally you want to find
the component by name. However, the names in DCOMCNFG do not necessarily exactly match those in the registry (typically it's a substring).
Armed with the AppID and some ideas about the component name, return to DCOMCNFG and start hunting:
Once you've found a candiate, open its properties and verify the AppID
If you've found it, select the 'Security' tab, select 'Customize' and 'Edit..' under 'Launch and Activation Permissions', and grant the required user the rights requested in the original error message.
Now you should be good to go. (complete with that warm and fuzzy feeling that you get from knowing that you haven't unduly compromised server security)