Set-DbaDatabaseOwner additional checks

[dataplat]

Set-DbaDatabaseOwner additional checks

[MikeFal]

I have a couple thoughts on resolving the mapped user issue:

• Throw a warning and continue if a mapped login is detected (like the other checks)
• Add a -Force switch. If -Force is declared, it will drop the user from the database and then set the owner. Otherwise it will throw a warning.

Thoughts?

[ClaudioESSilva]

Agree with the first one.

For the second one, why drop the user and not only set him as dbowner ?
Imagine someone set 'user1' (that have datareader permissions) as dbowner
but he was wrong and have to set 'user2' as dbowner, now, the user 'user1'
do not have the permissions (has lost datareader) he had before.

This makes sense to you?

No dia domingo, 21 de agosto de 2016, MikeFal [email protected]
escreveu:

I have a couple thoughts on resolving this:

• Throw a warning and continue if a mapped login is detected (like the
  other checks)
• Add a -Force switch. If -Force is declared, it will drop the user
  from the database and then set the owner. Otherwise it will throw a warning.

Thoughts?

—
You are receiving this because you are subscribed to this thread.
Reply to this email directly, view it on GitHub
#156 (comment),
or mute the thread
https://github.com/notifications/unsubscribe-auth/ASnfI98O4NMTLmddc-9uYZClY5uuac8Tks5qiHjHgaJpZM4JnazA
.

Cumprimentos,
Cláudio Silva

---

e-mail: [email protected]
linkedin: https://pt.linkedin.com/in/claudioessilva
twitter: http://www.twitter.com/claudioessilva

[MikeFal]

You can't set a login as database owner if it exists as a user in the database. Adding it to the db_owner role is not the same as setting the database owner to a login. That's why we'd have to drop the user. I agree with your concerns that if the user gets dropped, you lose any permissions the user had. This is why they would need to use -Force to perform the user drop.

Powershell is a sharp knife. Be careful you don't cut yourself with it. ;)

Of course, I'm open to not doing this and simply throwing a warning if the user is in the database.

[ClaudioESSilva]

That's true @MikeFal! I had forgotten this one!
That said I agree with the second one too 😄

[dansqldba]

Additionally, it's not possible for AD groups to be database owners is it? I think we came across this in the DbaJobOwner cmdlets as well but it was fixed there, might need a check for that too.

[dansqldba]

@MikeFal would you be happy for me to attempt to fix the issue I had with AD groups as database owners in Set-DbaDatabaseOwner? I think it was fixed in the "JobOwner" cmdlets you wrote, but not here, so I can probably just fix it with code copied or inspired from what you've written elsewhere.