Add User to Local Group using WMI?
Gerry Hickman
Is it possible to manage local group membership using WMI classes, e.g. add
a user to a local group?
I already have an ADSI solution; I'm interested in a WMI solution.
Thanks.
--
Gerry Hickman
London (UK)
Jialiang Ge [MSFT]
Here you go:
strComputer = "COMPUTER NAME"
Set colAccounts = GetObject("WinNT://" & strComputer & "")
Set objUser = colAccounts.Create("user", "TestUser1")
objUser.SetPassword "PASSWORD"
objUser.SetInfo
Set objGroup = GetObject("WinNT://"& strComputer &"/Administrators")
objGroup.Add "WinNT://"& strComputer & "/TestUser1"
This script creates a user "TestUser1" whose password is "PASSWORD" on the
specified computer and add the user to the Administrators group.
Regards,
Jialiang Ge (jia...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
==================================================
Get notification to my posts through email? Please refer to
http://msdn.microsoft.com/en-us/subscriptions/aa948868.aspx#notifications.
MSDN Managed Newsgroup support offering is for non-urgent issues where an
initial response from the community or a Microsoft Support Engineer within
2 business day is acceptable. Please note that each follow up response may
take approximately 2 business days as the support professional working with
you may need further investigation to reach the most efficient resolution.
The offering is not appropriate for situations that require urgent,
real-time or phone-based interactions. Issues of this nature are best
handled working with a dedicated Microsoft Support Engineer by contacting
Microsoft Customer Support Services (CSS) at
http://msdn.microsoft.com/en-us/subscriptions/aa948874.aspx
==================================================
This posting is provided "AS IS" with no warranties, and confers no rights.
Gerry Hickman
As I said in the original post, I already have the ADSI solution. My
question is how to do this using WMI classes.
--
Gerry Hickman
London (UK)
""Jialiang Ge [MSFT]"" <jia...@online.microsoft.com> wrote in message
news:qyxuUhG1...@TK2MSFTNGHUB02.phx.gbl...
Alex K. Angelopoulos dot dot again at
This has been a thorny issue for me, too. I explored ways to deal with local
group management about 4-5 years and the only built-in solution then was the
WinNT provider. Doing a check now on some resources and then exploring WMI
on even Win7, I don't find anything else for it.
Looking at the security-related methods and properties in WMI, what you'll
see is that properties are almost universally read-only, and methods that do
anything substantial are designed to perform tasks that you can't do with
WinNT: and ldap:. That's even more of an irritation to me now than it was
back then because I use PowerShell frequently and the way .NET binding to
those providers works forces you to map out method bindings on your own. : /
Is there a particular kind of situation you're trying to handle with this?
"Gerry Hickman" <gerry...@newsgroup.nospam> wrote in message
news:#YrafIH1...@TK2MSFTNGP04.phx.gbl...
Gerry Hickman
I remember your posts from the early MONAD days!
> This has been a thorny issue for me, too. I explored ways to deal with
> local group management about 4-5 years and the only built-in solution
> then was the WinNT provider. Doing a check now on some resources and
> then exploring WMI on even Win7, I don't find anything else for it.
>
> Looking at the security-related methods and properties in WMI, what
> you'll see is that properties are almost universally read-only, and
> methods that do anything substantial are designed to perform tasks that
> you can't do with WinNT: and ldap:.
Yes, that is exactly the problem I'm seeing. Some extensive testing
suggests WMI is slightly more accurate when dealing with local accounts,
especially service accounts. I also find it more concise when it comes
to SID to account translation.
> That's even more of an irritation to
> me now than it was back then because I use PowerShell frequently and the
> way .NET binding to those providers works forces you to map out method
> bindings on your own. : /
My take on it, was that WMI could have been a potentially a very
powerful technology, but it's terribly damaged by
1. Wrappers contain the bad as well as the good, and ultimately end up
stuck in time.
2. Providers are closed source, part of Windows, and not easily updated
3. Bugs lie broken for years and can't be fixed because of "backward
compatibility"
4. Providers get added/removed on a whim (e.g. MSI Provider in Win2003).
Technologies like PowerShell then add another wrapper layer and no one
fixed the underlying problem. I have a number of open WMI cases with
Microsoft, nothing is being done.
There's also a major problem when using Associators on many objects
where the performance is terrible because the enum algorithm is flawed!
> Is there a particular kind of situation you're trying to handle with this?
Yes. I have a WMI application that sets up templated security on
numerous SQL back-end data servers, such that dev teams can create
database applications without admin rights. It involves creating folders
and shares, setting FileSystem security and Share security, setting DCOM
permissions etc.
WMI does not seem able to create a new folder (without hacking) and I
then need to set security and add users to groups etc. Since my app uses
handles to WMI objects I don't want to have to switch out of that
context into an ADSI context back on the client.
I asked about creating new folders in the PowerShell group, but they
didn't seem to understand the difference between a local machine context
and a UNC context (which relies on SMB) - it's not the same thing!
Quote from "Brandon Shell MVP"
"In regards to your need for a robust app. I think you have serious problems
at work if you need a fully robust client server application just to create
folders."
LOL!
--
Gerry Hickman (London UK)
Hongye Sun [MSFT]
Jialiang is in a training this week and I am his backup on this issue.
After investigating into this issue, these is no way to add a user to group
by only WMI without WinNT provider. You can only read accounts and groups
information in WMI. So WinNT provider seems to be the only way.
I appreciate you sharing your thoughts on the potential issues of switching
context between WMI objects and ADSI objects. I can understand. If you
encounter any issue in performance, robustness or bug, please don't
hesitate to contact us or support center. We will try our best to help.
Regards,
Hongye Sun (hon...@online.microsoft.com, remove 'online.')
Microsoft Online Community Support
Delighting our customers is our #1 priority. We welcome your comments and
suggestions about how we can improve the support we provide to you. Please
feel free to let my manager know what you think of the level of service
provided. You can send feedback directly to my manager at:
msd...@microsoft.com.
This posting is provided "AS IS" with no warranties, and confers no rights.
Gerry Hickman
> Jialiang is in a training this week and I am his backup on this issue.
Ah OK. I thought he might be having a nice holiday:)
> After investigating into this issue, these is no way to add a user to group
> by only WMI without WinNT provider. You can only read accounts and groups
> information in WMI. So WinNT provider seems to be the only way.
OK, thank you for clarification.
> I appreciate you sharing your thoughts on the potential issues of switching
> context between WMI objects and ADSI objects. I can understand. If you
> encounter any issue in performance, robustness or bug, please don't
> hesitate to contact us or support center. We will try our best to help.
The issue (as I think you already understand) is that we have to switch
context on the client. We lose the remote server handle and end up
making a new connection in ADSI context - this is not good programming.
It's the same reason why creating a new folder using SMB and UNC is
wrong. Everything in WMI should be done via the handle to the
SWbemServices object.
I don't believe any of the new technologies such as .NET and PowerShell
are any better. New wrappers, but the underlying problem is the same.
Alex K. Angelopoulos dot dot again at
also got nothing, as you probably guessed. I can think of workarounds to do
the desired work in specific situations, but they're not a fix for the
context issue.
"Gerry Hickman" <gerry...@newsgroup.nospam> wrote in message
news:uppcHal2...@TK2MSFTNGP04.phx.gbl...