Microsoft Graph, AppProfile, Powershell, intune to export user and computer details

 Do with what you will, use the handy # Write-Host ($SpecificVar | Format-List | Out-String) # to see what is available.

# You need an appProfile with intune permissions
$tenantId = 'xxxxxxxxxxxx' # You Tenant ID
$appId = 'xxxxxxxxxx'  # Application (client) ID
$appSecret = 'xxxxxxxxxxx' #Value
$body = @{  
    grant_type    = "client_credentials"  
    scope = "https://graph.microsoft.com/.default"  
    client_id     = $appId  
    client_secret = $appSecret  
}  
 
$response = Invoke-RestMethod -Uri "https://login.microsoftonline.com/$tenantId/oauth2/v2.0/token" -Method Post -Body $body -ContentType "application/x-www-form-urlencoded"  
$token = $response.access_token  
 

# connecting as the application with the permission on the service
Connect-MgGraph -AccessToken ($Token |ConvertTo-SecureString -AsPlainText -Force)  
#disConnect-MgGraph
  #(get-mgcontext).Scopes
  # (get-mgcontext)
   if (get-mgcontext) {write-host "Connected to O365" -ForegroundColor Green}
   else {   write-host "Disconnected from O365"   break}
 

$allMGusers = get-mguser -Top 200
# $allMGusers = get-mguser -All # This can take time in a big environment.
 

$allMGusers.Count
#  $allMGusers[222] # Lets just see what 222 looks like?
 

$SpecificUser = $allMGusers | Where-Object {  $_.UserPrincipalName -like 'David.Colvin1*' }  
$SpecificUser.Count
 

# Write-Host ($SpecificUser | Format-List | Out-String) # dump it all to look at it.
Write-Host  $SpecificUser.UserPrincipalName $SpecificUser.Id # Some things I am interested in
 

# A UPN can also be used as -UserId.
$UserDevices = Get-MgUserOwnedDevice -UserId $SpecificUser.Id
 

foreach ($device in $UserDevices) {
    $deviceDetails = get-mgdevice -DeviceId $device.Id
    write-host $deviceDetails.DisplayName';'$deviceDetails.Id';'$deviceDetails.OperatingSystemVersion';'$SpecificUser.UserPrincipalName';'$SpecificUser.Id
    # Write-Host ($deviceDetails | Format-List | Out-String) # dump it all to look at it.
                                    }
 

To check if you are a local administrator

To check if you are a local administrator on a Windows machine using the command line, you can use the following methods: 

### Method 1: Using the `net user` command 

You can check the groups that your user account belongs to with the `net user` command followed by your username and the `/domain` flag if you are on a domain: 

 

Cmd.exe 

net user yourusername 

 

Or if you are checking for the account that's currently logged in: 

cmd .exe

net user %USERNAME% 

 

  

Look for the "Local Group Memberships" section in the output. If you see `Administrators` listed there, your account is a member of the local Administrators group. 

 

Using the `whoami /groups` command 

This command will list all the groups that the current user is a member of, along with their security identifiers (SIDs): 

 

Cmd.exe 

whoami /groups 

 

Search for a group named `BUILTIN\Administrators` or look for the SID `S-1-5-32-544`, which corresponds to the Administrators group. If the group has the attribute `Enabled group`, it means your account is currently acting with administrative privileges. 

Using the `net localgroup` command 

You can also list all members of the Administrators group using the `net localgroup` command: 

 

Cmd.exe 

net localgroup Administrators 

Check if your username is listed in the output. If it is, then your account is a member of the local Administrators group. 

Choose the method that you find most convenient. It is worth noting that even if your user account is a member of the Administrators group, User Account Control (UAC) may require you to explicitly run programs "as administrator" to perform tasks that require elevated privileges.

Using PowerShell 

If you prefer to use PowerShell, you can run the following command to check if the current user is part of the Administrators group: 

powershell.exe

$currentPrincipal = New-Object Security.Principal.WindowsPrincipal([Security.Principal.WindowsIdentity]::GetCurrent()) 

$currentPrincipal.IsInRole([Security.Principal.WindowsBuiltInRole]::Administrator) 

 

 

This will return `True` if you are running as an administrator, and `False` otherwise. 

  

Quickly create some accounts in Active Directory for testing

# Define the password for the accounts
$password = ConvertTo-SecureString -AsPlainText "Password11" -Force

# Create 100 user accounts (user001 to user100)
1..100 | ForEach-Object {
    $username = "computer{0:D3}" -f $_
    #$username = "user{0:D3}" -f $_
    #New-ADUser -Name $username -SamAccountName $username -UserPrincipalName "$username@enron.com.au" -AccountPassword $password -Enabled $true -Path "CN=Users,DC=enron,DC=com,DC=au" -PassThru
    New-ADComputer -Name $username -SamAccountName $username -UserPrincipalName "$username@enron.com.au" -AccountPassword $password -Enabled $true -Path "CN=Computers,DC=energy,DC=com,DC=au" -PassThru
}

Need to rename an Active Directory (2019 and later) and dont want the life story?

 Here is a bullet point list of the commands to run in order based on the provided text:

On the DC, from an Admin Command Prompt:

rendom /list
Edit the Domainlist.xml file it created to replace all existing domain names with the new domain name, including the NetBIOS name if it’s changed.

rendom /showforest
rendom /upload

Ensure replication is complete, optionally using

repadmin.exe /syncall /d /e /P /q DomainNamingMaster-HostName

rendom /prepare
rendom /execute

After domain controllers restart, log on using the new domain name.
Restart the pretty much everything twice after all domain controllers are back online.

Update GPO linkages with the new domain name using gpfixup . If FQDN is changed:

gpfixup /olddns:old-domain.local /newdns:new-domain.com

If NetBIOS name is changed:

gpfixup /oldnb:OLD-NetBIOS /newnb:NEW-NetBIOS

If needed, synchronise group policy changes with repadmin.exe /syncall /d /e /P /q DC-HostName NewDomainDN

Rename domain controllers with netdom commands:

netdom computername old.computer.name /add:new.computer.name

followed by

netdom computername old.computer.name /makeprimary:new.computer.name

Reboot domain controllers.
Reboot all domain member computers, workstations, and servers twice.

If using domain-based DFS namespaces, update any orphaned paths.
Run rendom /clean to clean up old domain references and unfreeze the forest configuration.

rendom /clean

Open DNS Manager create the new zone, reboot and after you can delete the old domain DNS zone.

Remove the Active Directory Domain Services role from Control Station if applicable.
 
The domain rename process is complex and can have far-reaching effects on your network. It should not be undertaken lightly and requires thorough planning and testing.

 

Time and date on Server 2019 (timedate.cpl or tzutil)

 It is 2020 and Microsoft still believe everyone is in the USA (or covid central as it is now known). So we always have to change, normally an Administrator can do this, but in Server 2019, not even normal admin users can do this, you need to elevate the control.

 

You can change the time zone in the control panel, and it will fail with a notification that you do not have the permissions to perform this task and that you should contact the administrator.

If you try and change it in the 'settings app' you do not even get an error message; the dialog simply resets itself to the original time zone after exiting. 

 

But they way to do it is starting the control panel's "timedate.cpl" applet directly, elevated with administrative rights. 

 

You can also use the timezone utility, 'tzutil /s "AUS Eastern Standard Time"'