function get-SID {            
param (            
 [string]$computername = $env:COMPUTERNAME            
)            
            
Get-WmiObject -Class Win32_AccountSID -ComputerName $computername |            
foreach {            
 $da =  (($_.Element).Split(".")[1]).Split(",")            
 $sid = ($_.Setting -split "=")[1] -replace '"',''            
            
 $props = [ordered]@{            
 Domain = ($da[0] -split "=")[1] -replace '"',''            
 Account = ($da[1] -split "=")[1] -replace '"',''            
 SID = $sid            
 }            
             
 New-Object -TypeName PSObject -Property $props            
}            
            
}

Pass a computer name into the function – default is local machine.

Use the AccountSID class which links Win32_SystemAccount and Win32_SID.  For each returned instance clean up the data and create an object with three properties – domain, account and SID.

You will see more than you thought – some very useful information buried in there

function remove-profile {            
 param (            
  [parameter(Mandatory=$true)]            
  [string]$username            
 )            
            
 $user = Get-CimInstance -Class Win32_UserAccount -Filter "Name = '$username'"             
 $profile = Get-CimInstance -Class Win32_UserProfile -Filter "SID = '$($user.SID)'"            
 $folder = Split-Path -Path $profile.LocalPath -Leaf            
            
 if ($folder -eq $username){            
  Remove-CimInstance -InputObject $profile            
 }            
 else {            
  Write-Warning -Message "Could not resolve profile and user name"             
 }            
            
}

I’m going to start with the CIM cmdlets as these are the way of the future in PowerShell v3.

Start by taking a user name as a parameter. Get the Win32_UserAccount class object representing that account. use the SID to find the profile via Win32_UserProfile.  Take the profile’s localpath and split it. The last part of the path should match the username – if it does then delete the profile otherwise throw a warning. Deleting the profile does delete the folder under c:\users

If you have to use the WMI cmdlets then its very similar

function remove-profile {            
 param (            
  [parameter(Mandatory=$true)]            
  [string]$username            
 )            
            
 $user = Get-WmiObject -Class Win32_UserAccount -Filter "Name = '$username'"             
 $profile = Get-WmiObject -Class Win32_UserProfile -Filter "SID = '$($user.SID)'"            
 $folder = Split-Path -Path $profile.LocalPath -Leaf            
            
 if ($folder -eq $username){            
  Remove-WmiObject -InputObject $profile            
 }            
 else {            
  Write-Warning -Message "Could not resolve profile and user name"             
 }            
            
}

Just the name of the cmdlets change.

You can’t use WMI to delete local accounts as explained on page 363 of PowerShell and WMI 

If you have profiles generated by AD accounts you’ll need to find the SID from the AD account and use that as the filter for deletion

Want to find out?

function get-logedonuser {            
param (            
 [string]$computername = $env:COMPUTERNAME            
)            
Get-WmiObject -Class Win32_LogonSession -ComputerName $computername |            
foreach {            
 $data = $_            
            
 $id = $data.__RELPATH -replace """", "'"            
 $q = "ASSOCIATORS OF {$id} WHERE ResultClass = Win32_Account"            
 Get-WmiObject -ComputerName $computername -Query $q |            
 select @{N="User";E={$($_.Caption)}},             
 @{N="LogonTime";E={$data.ConvertToDateTime($data.StartTime)}}            
}            
}

Use the Win32_LogonSession class and then find the associated Win32_Account classes.  It does work for domain and local accounts

This is the quickest answer I’ve come up with

The Win32_Usergroup is one of the association classes. In the case it has all the information we need.  Use the GroupComponent to restrict the data to the admins groups.  Split the Part component and then clean up the second element to get the name.

For reference the two elements look like this:

GroupComponent : \\RSLAPTOP01\root\cimv2:Win32_Group.Domain="RSLAPTOP01",Name="Administrators"

PartComponent  : \\RSLAPTOP01\root\cimv2:Win32_UserAccount.Domain="RSLAPTOP01",Name="Administrator"

If you want to pick off the domain to show the difference between local and domain accounts then manipulate $data[0]  like this

In this post http://itknowledgeexchange.techtarget.com/powershell/current-logged-on-user/ we discovered how to find the current logged on user.  I want to extend that a bit and add the information about that users desktop.

We start with the script in our earlier post.

We add a query to get the desktop associated with the current user  – - $query2

That query returns the information about the desktop. Its displayed after the user information and I’ve selected the items I want to display.

This is a good example of extending an existing script when you find out how to do a bit more digging.

I think we’ve about exhausted the WMI information on users and groups for now – so its time to find another topic.

We can find the groups on a machine using WMI

PS> Get-WmiObject -Class Win32_Group | select Name, Description, SID, LocalAccount | format-list

Name         : Administrators
Description  : Administrators have complete and unrestricted access to the computer/domain
SID          : S-1-5-32-544
LocalAccount : True

etc etc

But what would be good would if we could also check membership at the same time

By now this format should be familiar.  We get the groups and for each group we use the ASSOCIATORS query to find the group members using the  Win32_UserAccount. We use string substitution to display the group information and display the caption property to get the domain and user name

Last time we looked at getting the currently logged on user. This time we’ll discover the user profiles that have been defined on our system.

We use Win32_UserProfile and foreach we find the user account associated with the SID – this is lifted straight from our look at share permissions. We use the technique from last time to add a property to the current object only this time are using the pipeline object (originally from our WMI query).

We can then pipe into Format-List and perform our display including converting the dates.

This class only appears to be available on Windows Vista SP1 and above – see http://msdn.microsoft.com/en-us/library/ee886409(VS.85).aspx for details.

Get-WmiObject -List win32* | where {$_.Name -notlike “*perf*”}

to see the available classes and pick something that catches my eye. Sometimes it leads to a series of posts and other times its a single post.

This time my eye was caught by Win32_LogonSession – which returns the logged on user

PS> Get-WmiObject -Class Win32_LogonSession

AuthenticationPackage : NTLM
LogonId               : 188568
LogonType             : 2
Name                  :
StartTime             : 20100422181039.691600+060
Status                :

AuthenticationPackage : NTLM
LogonId               : 188537
LogonType             : 2
Name                  :
StartTime             : 20100422181039.691600+060
Status                :

OK thats not good ‘cos I know I’m the only one logged in – unless its my imaginary friend

PS> Get-WmiObject -Class Win32_SessionProcess | select Antecedent

Antecedent
———-
\\.\root\cimv2:Win32_LogonSession.LogonId=”188568″
\\.\root\cimv2:Win32_LogonSession.LogonId=”188568″

etc

Shows that LogonId 188568 is the latest as Win32_SessionProcess shows the processes associated with the current logged on user.

We need to take that fact and find the logged on user

We take our session process – select first 1 and we only need the Antecedent property. We then split it on a “=” sign and do 2 replaces to clean it up.  I was surprised when the operators combined like that.

The here-string defines a the logon types. We find the Win32_LogonSession associated with the logonid and then get the ASSOCIATORS to find the associated user.

We use Add-Member to add the user name property to the session information and then use a couple of calculated fields to display the logon type and the logon date