Trusted Connections: There's more to it than that
Yesterday I resolved some jobs issues on a couple of my sites by switching trusted connection off (see Don't use trusted connection...). When talking to some of the guys here at the office, it became obvious that there is more to this issue than just trusted connections. As a matter of fact, some people hold that the prefered method is to use trusted connections (your username and password aren't sitting in your web.config for the world to see should some malevolent soul gain access to your box).
So, here's the thought process: your website runs under the authority of the identity selected in the app pool of the web site (go to IIS, look at the Home Directory tab of your website to identify your app pool then go to the identity tab on the properties for the application pool you're using).
That user is the account that must connect to the database. When I checked for the account in my database, it wasn't explicitly included. I added the user, gave the permissions I desired for running Community Server, updated my web.config to remove username and password, added back trusted connection and tested...
Well, what do you know; all jobs are running!
Now, why did my site work at all if that user wasn't in my database for the site? I can only make a few guesses - maybe I'll update this post when I have a definative answer but I'm leaning heavily towards miracle right now... Ok, not really - there are logins at the server level in SQL and I'm assuming that my user had some access through that but for some reason the user could not run all of the jobs. By adding the user to my database and giving it explicit permissions I've fixed my issue. If I learn more, I'll let you know.
Short version of the story: trusted connections are ok!