Managed workstations

This topic contains 10 replies, has 3 voices, and was last updated by Profile photo of TJ Anon TJ Anon 2 years, 4 months ago.

  • Author
    Posts
  • #17363
    Profile photo of TJ Anon
    TJ Anon
    Participant

    I need to be able to create a managed workstation with powershell. When we do this manually, the process requires that we have a GUID or UUID to identify the workstation. I am soooo confused. I've found at least 3 different ways to get GUIDs along with 3 different GUIDs to match. The one that works is the one we look up in a manual process. What I am searching for is:

    1) which command creates a managed workstation?
    2) how do I get the "real" GUID of the workstation that we want to manage (via powershell)?

    The commands that retrieve the wrong number:
    (get-ciminstance Win32_ComputerSystemProduct).UUID
    (get-adcomputer "mycomputer").objectGUID

    The manual process is quite the procedure. However, this is the one procedure that gets me the correct GUID for the workstation that will work when creating a managed workstation. It goes like this:
    Run wbemtest.
    Connect.
    Connect again (root\cimv2)
    Click on the Enum classes button .
    Select recursive.
    Click OK.
    Scroll down and find win32_ComputerSystemProduct and double click it
    In top window you will find the UUID entry

    If anyone can shed some light on how to do this, I will be very appreciative. I would also be appreciative of any terms that might help me search google. "Managed workstation" is too vague a phrase using too common words. It's not turning up much. Thanks for your help.

  • #17364
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    What do you mean by a "managed workstation"? Which product are you using?

    To get at the same value described by your manual process, do this:

    (Get-CimClass Win32_ComputerSystemProduct).CimClassQualifiers['UUID'].Value
    
  • #17365
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    I should note, though: this value is not likely to be a GUID for a particular workstation. On the two computers I tested, I got the same value of {FAF76B96-798C-11D2-AAD1-006008C78BC7} , which turns up all over the place in search engines. I'm not sure what that GUID actually identifies.

  • #17366
    Profile photo of TJ Anon
    TJ Anon
    Participant

    In Active Directory, right click on an OU to create a New Computer. Give it a name, press Next, and the next window has a box that you can click to make a "managed workstation". That's the goal. We want to do that with powershell. Heh.. seems like Guids are not "globally unique" after all. 😉

  • #17367
    Profile photo of Don Jones
    Don Jones
    Keymaster

    You can retrieve that information by running [b]Get-WmiObject -Class Win32_ComputerSystemProduct | Select -ExpandProperty UUID[/b]. It's similar – although less programmer-y – than the Get-CimInstance approach you used.

    When you use Wbemtest, don't look at the UUID in the "qualifiers" box; that's not the same thing. You're after the UUID in the "Properties" list. The "qualifiers" list almost always contains a UUID; it's the UUID for the WMI class itself. You're right in that many things in Windows use Universally Unique Identifiers – the UUID for a given class should always be the same on every computer; it isn't unique per-computer.

    You might need to be more specific about what "managed workstation" means to you, as it's definitely used in a lot of different ways. I'm not sure I understand what you mean by it here.

  • #17368
    Profile photo of TJ Anon
    TJ Anon
    Participant

    Don I get two entirely different numbers by using your command vs. the manual procedure. Manual = {FAF76B96-798C-11D2-AAD1-006008C78BC7}. get-wmiobject = 4C4C4544-004A-3710-8036-C7C04F5A5631.

    Jeeze. There are several of us working on this project. I got the wrong information. You're right. the get-wmiobject command is what we need. You guys know if there is a posh command to create a managed workstation?

  • #17369
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    Ah, okay. You're talking about the "managed computer" feature of WDS / Active Directory. For that, you had the right command already, and your manual process was wrong.

    (get-ciminstance Win32_ComputerSystemProduct).UUID

    Or the Get-WmiObject command Don posted; they both retrieve the same value in slightly different ways. Either way, that's the one you want for your AD accounts.

  • #17370
    Profile photo of Don Jones
    Don Jones
    Keymaster

    A UUID is a form of GUID; a GUID is "likely to be unique" because there are so many possibilities, but not guaranteed. Many, many, many things use UUIDs and GUIDs to uniquely identify themselves. For example, COM classes all have a GUID. Active Directory users have a kind of GUID for their Security Identifier (SID; SIDs derive from GUIDs but also contain other information like a domain identifier). Anyway, lots of things use GUIDs/UUIDs as identifiers.

    Natively, PowerShell's only command for creating new AD computers is New-ADComputer, and it doesn't contain an explicit means for creating a managed computer (e.g., no explicit means for assigning a GUID/UUID to the new object). However, it may be possible to set the property using the command. We just need to figure out what the underlying AD attribute name is.

    I'll note that in my GUI, it says "managed computer" not "managed workstation." Those details can make all the difference when doing a Google search! A little digging suggests that the attribute is netbootGUID. So you'd do something like...

    New-ADComputer -OtherAttributes @{'netbootGUID'=$guid}

    Now, you have to provide all the other command parameters needed to make it work, that just shows how to inject the GUID, and it assumes you've put the GUID into $guid first, like this:

    $guid = Get-WmiObject -Class Win32_ComputerSystemProduct | Select -Expand UUID

    I'll note that there may be a data type mismatch, so that might not work exactly as-is – i don't have access to a machine to test on at the moment, but that's the general gist. Searching for "powershell netbootguid" might turn up more examples.

    There's a longer discussion of this at http://social.technet.microsoft.com/Forums/scriptcenter/en-US/7080ef9f-f443-4c81-8c41-942dce37ff23/powershell-creating-a-computer-account-in-active-directory-from-outside-the-domain?forum=ITCG, if you're interested.

  • #17371
    Profile photo of TJ Anon
    TJ Anon
    Participant

    Thanks for the info, Don. I'll try it this evening.

  • #17372
    Profile photo of Dave Wyatt
    Dave Wyatt
    Moderator

    Just played with this a bit on a test VM. The "netbootGUID" attribute takes a byte array. When you create this attribute manually with AD Users and Computers, it expects a GUID string and converts it to a byte array for you under the hood (and the string must include curly braces, which is probably what was giving you trouble earlier.) Here's how you can assign the GUID to an AD computer account with PowerShell. This code assumes that you're running the commands on a computer that's already joined to the domain:

    $guid = [guid](Get-WmiObject Win32_ComputerSystemProduct).UUID
    Set-ADComputer $env:COMPUTERNAME -Replace @{ netbootGUID = $guid.ToByteArray() }
    

    This takes the local computer's Win32_ComputerSystemProduct.UUID value that you've already seen, and casts it to a [System.Guid] object. System.Guid has a method called ToByteArray() which converts to the format that AD requires.

  • #17376
    Profile photo of TJ Anon
    TJ Anon
    Participant

    Awesome. Saved me a lot of head banging, Dave. Thank you!

You must be logged in to reply to this topic.