The other solution is to (automate) the removal of references of the account used.
e.g. CM install: - "SMS Admins" group, easy to clean up - Class access in CM. Can't be removed without using another account - SQL. This is rather difficult I figured. Doable, by transferring DBs to sa or SYSTEM (as shown below) and revoking access to a point where the installer account can be deleted. Although I noticed that somehow the installer account shows up again as SQL-login, but is not that deeply embedded anymore Are you guys also using a service account? The problem is partially the same, it does get referenced at many locations, especially SQL is very annoying (e.g. "endpoint"-entries), hence it may get an issue if the account expires or gets deleted. -R From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Montag, 18. November 2013 20:00 To: [email protected] Subject: RE: [mssms] RE: help !! - sql sid's Most installs I do, I do everything with a service account (all operations are carried out while logged in as the service account), then lock it down after. Saves so much grief down the road. When it comes time to apply a big update, or upgrade the system, you just reverse the lockdown settings, and use your service account. Another perk, when your DBA locks out their account due to a password change and having remote sessions, it wont lock out critical business databases :D Christopher Catlett Consultant | Detroit MCTS_2013_small Sogeti USA Office 248-876-9738 |Fax 877.406.9647 26957 Northwestern Highway, Suite 130, Southfield, MI 48033-8456 <http://www.us.sogeti.com/> www.us.sogeti.com From: [email protected] [mailto:[email protected]] On Behalf Of Roland Janus Sent: Monday, November 18, 2013 1:50 PM To: [email protected] Subject: RE: [mssms] RE: help !! - sql sid's You're saying you recommend to install everything with a service account? -R From: [email protected] [mailto:[email protected]] On Behalf Of [email protected] Sent: Montag, 18. November 2013 16:40 To: [email protected] Subject: [mssms] RE: help !! - sql sid's I'm late to the party, but I've resolved issues on a DB (owner was a SID that no longer existed.. Curse employee's that don't use service accounts when setting up production stuff.) I just detached the database, and reattached it. Christopher Catlett Consultant | Detroit MCTS_2013_small Sogeti USA Office 248-876-9738 |Fax 877.406.9647 26957 Northwestern Highway, Suite 130, Southfield, MI 48033-8456 <http://www.us.sogeti.com/> www.us.sogeti.com From: [email protected] [mailto:[email protected]] On Behalf Of Stuart Watret Sent: Monday, November 18, 2013 10:32 AM To: [email protected] Subject: [mssms] RE: help !! - sql sid's I'm celebrating with chocolate. So I was bashing away like a karate student wondering why I couldnt get me as the owner; stumbled across a blog that reveresed the proposition, ie made sa the owner again using alter authorization. This worked straight away; I have done three times my sql quota for the year, lost weight and got a headache. The next time someone says "just move the log files to another volume"; I'll ignore them. KB issue for post moved db's (don't put the db in single user mode, try it first) kB2709082 Code for resetting the owner USE dbname ALTER AUTHORIZATION ON DATABASE::dbname TO [sa] Stuart Watret Offshore - IT Ltd _____ From: [email protected] <[email protected]> on behalf of Stuart Watret <[email protected]> Sent: 18 November 2013 15:22 To: [email protected] Subject: [mssms] RE: help !! - sql sid's hooray........ well done me. Stuart Watret Offshore - IT Ltd _____ From: [email protected] <[email protected]> on behalf of Stuart Watret <[email protected]> Sent: 18 November 2013 15:07 To: [email protected] Subject: [mssms] RE: help !! - sql sid's ok so I think the master db thinks the owner is me, and the actual db thinks it's sa......... how to resolve? ..honestly if you leave this thread long enough I'll fix it myself :) Stuart Watret Offshore - IT Ltd _____ From: [email protected] <[email protected]> on behalf of Stuart Watret <[email protected]> Sent: 18 November 2013 14:40 To: [email protected] Subject: [mssms] RE: help !! - sql sid's found a bit more tsql and that shows a different sid between the actual db and what the master thinks it should be, but ......how do we translate that to accounts? Stuart Watret Offshore - IT Ltd _____ From: [email protected] <[email protected]> on behalf of Stuart Watret <[email protected]> Sent: 18 November 2013 14:32 To: [email protected] Subject: [mssms] help !! - sql sid's Moved the sccm log file this weekend using the detach/attach method. Hit a snag with the "Trustworthy" issue; resolved that. System up and consoles connecting, but I can't import any new devices using the name/mac screen. Error states, "could not get next available key"......... the db owner sid recorded in the master db differs from the db owner sid recorded in "mt sccm db". Correct this using Alter authorization, blah blah. The issue I have is I'm not sure what to compare to find the difference; and as luck would have it, large migration tonight and need to add some devices. ANy thoughts? Stuart Watret Offshore - IT Ltd
<<image001.jpg>>
