List a Client Machine informations with PowerShell

Here are two scripts, which can assist in getting hardware information about the computers on an active directory network. It'll get you the following information in a CSV file:

  1. Hostname
  2. Model
  3. RAM
  4. CPU
  5. Serial Number
  6. Manufacturer
  7. Operating System
  8. HDD Capacity
  9. HDD Space
  10. IP Address

If your DC has PowerShell V2 use this:

Import-Module ActiveDirectory
$ComputerList = Get-ADComputer -filter * -Properties *
$csvpath = "C:\users\icuadminaccount\Desktop\Computers.csv"
foreach ($Computer in $ComputerList) {
$computerSystem = Get-WmiObject -ComputerName $Computer.Name -Class CIM_ComputerSystem
$output = "System Information for: " + $computerSystem.Name +"`n"
$output = $output + "Model: " + $computerSystem.Model +"`n"
$output = $output + "RAM: " + "{0:N2}" -f ($computerSystem.TotalPhysicalMemory/1GB) + "GB"+"`n"
$computerCPU = Get-WmiObject -ComputerName $Computer.Name -Class CIM_Processor
$output = $output + "CPU: " + $computerCPU.Name +"`n"
Out-file -FilePath $csvpath -append
$computerBIOS = Get-WmiObject -ComputerName $Computer.Name -Class CIM_BIOSElement
$output = $output + "Serial Number: " + $computerBIOS.SerialNumber +"`n"
$output = $output + "Manufacturer: " + $computerBIOS.Manufacturer +"`n"
Out-file -FilePath $csvpath -append
$computerOS = Get-WmiObject -ComputerName $Computer.Name -Class CIM_OperatingSystem
$output = $output + "Last Reboot: " + $computerOS.LastBootUpTime +"`n"
$output = $output + "Operating System: " + $computerOS.caption + ", Service Pack: " + $computerOS.ServicePackMajorVersion +"`n"
Out-file -FilePath $csvpath -append
$computerHDD = Get-WmiObject -ComputerName $Computer.Name -Class Win32_LogicalDisk -filter "DeviceID = 'C:'"
$output = $output + "HDD Capacity: " + "{0:N2}" -f ($computerHDD.Size/1024) + "GB" +"`n"
$output = $output + "HDD Space: " + "{0:P2}" -f ($computerHDD.FreeSpace/1024) + " Free (" + "{0:N2}" -f ($computerHDD.FreeSpace) + "KB)" +"`n"
$output | Out-file -FilePath $csvpath -append

If your DC has PowerShell V3+ use this:

Import-Module ActiveDirectory
$ComputerList = Get-ADComputer -filter * -Properties *
$csvpath = "C:\users\icuadminaccount\Desktop\Computers.csv"
foreach ($Computer in $ComputerList) {

$computerSystem = Get-CimInstance CIM_ComputerSystem
$computerBIOS = Get-CimInstance CIM_BIOSElement
$computerOS = Get-CimInstance CIM_OperatingSystem
$computerCPU = Get-CimInstance CIM_Processor
$computerHDD = Get-CimInstance Win32_LogicalDisk -filter "DeviceID = 'C:'"

$output = "System Information for: " $computerSystem.Name -BackgroundColor DarkCyan
$output = $output + "Manufacturer: " + $computerSystem.Manufacturer
$output = $output + "Model: " + $computerSystem.Model
$output = $output + "Serial Number: " + $computerBIOS.SerialNumber
$output = $output + "CPU: " + $computerCPU.Name
$output = $output + "HDD Capacity: " + "{0:N2}" -f ($computerHDD.Size/1GB) + "GB"
$output = $output + "HDD Space: " + "{0:P2}" -f ($computerHDD.FreeSpace/$computerHDD.Size) + " Free (" + "{0:N2}" -f ($computerHDD.FreeSpace/1GB) + "GB)"
$output = $output + "RAM: " + "{0:N2}" -f ($computerSystem.TotalPhysicalMemory/1GB) + "GB"
$output = $output + "Operating System: " + $computerOS.caption + ", Service Pack: " + $computerOS.ServicePackMajorVersion
$output = $output + "User logged In: " + $computerSystem.UserName
$output = $output + "Last Reboot: " + $computerOS.LastBootUpTime
$output | Out-file -FilePath $csvpath -append

Group Managed Service Accounts

#Create KDC root Key (This command takes 10 hours to take effect)


Add-KDSRootKey -EffectiveImmediatly

#Install a Group Managed Service Account and configure it to work with the "Web Servers" group and a DNS CNAME which resolves to all machines.

New-ADSeriveAccount -Name GroupMSAAccount -DNSHostName WebClusterA.mydomain.local -PrincipalAllowedToRetrieveManagedPassword "Web Servers"

#Target machines need the RSAT-AD-PowerShell feature instralled

Invoke-Command -ComputerName Web01,Web02,Web03 -ScriptBlock { Install-WindowsFeature RSAT-AD-PowerShell }

#Install the GMSA

Install-ADServiceAccount GroupMSAAccount

#On the target server

Install-ADServiceAccount GroupMSAAccount

Test-ADServiceAccount -Identity GroupMSAAccount

Go to your service you wish to run on a service account, on the logon tab, set the credentials for the service as a network account. Use the browse button to find your MSA (You'll need to change the location to the domain to find the account instead of the local machine. Remove the pre-populated password from the fields and save.

Managed Service Accounts (For Single Machine)

PowerShell is required to create a service account. Once created it can be managed  in the GUI.


#Create the MSA

New-ADServiceAccount -Name MyAppSrv -RestrictToSingleComputer

#Add the Machine to be used with the account

Add-ADComputerServiceAccount -Identity SRV-01 -ServiceAccount MyAppSrv

#You can test to see if it is working (it won't... yet)

Test-ADServiceAccount -Identity MyAppSrv

#Finally, install the account and test again

Install-ADServiceAccount MyAppSrv

Test-ADServiceAccount -Identity MyAppSrv

#Next, Configure the service to use the account.

Go to your service you wish to run on a service account, on the logon tab, set the credentials for the service as a network account. Use the browse button to find your MSA. Remove the pre-populated password from the fields and save.



Step by Step: Building a SSO Federated Domain with Office 365


DC1 - Domain controller for techshizz.local
ADFS - Will run the Federation Services Role
ADFSProxy - Will run the Federation Services Proxy role
Client1 - Will act as a testing machine for SSO

Part 1- Preparing for ADFS

Create a certificate request on the ADFS server via the IIS console and submit it to a 3rd party Certificate Authority. Then we Install the certificate in IIS, Export it and install it on the ADFS server and then copy it to the DC and the ADFSProxy server. Finally we create a DNS record.

When I set this up in a real world environment, the O365 world was hosting the email so it was not an on-premises or hybrid environment. I've learned that if this is the case only a standard SSL certificate is needed. If your environment has an on-premises or hybrid exchange then you may need a UCC certificate to cover the autodiscover and mail CNAME address like and My steps below are for an Office 365 hosted email environment but I have noted the steps to creating a custom certificate via the mmc snap it should you need to try it that way.
When creating the certificate request in IIS configure as follows:
If you did need to add the additional Subject alternative names in the certificate request you need to configure the request like this from the MMC and certificates snap in.
  • Provide a certificate Friendly name
  • Add the Common Name (CN) for the ADFS server. Like (other guides use the pre-fix sts (Secure Token Signing) like this: but it really does not matter.
  • Add and Alternative name (select DNS).
  • Select "Server Authentication" as the cert type
  • Change the Key Type to "Exchange"
  • Change the Key Size to 2048
  • Make the Private Key Exportable
  • Continue and export the file. Leave the format as Base64.
  • Locate the txt file, copy and submit the request to the CA. You should receive the certificate from the CA in a zip file.
  • Extract the certificate and import it into the MMC
  • Export the Certificate and the copy it to the DC and ADFSProxy
  • In your public DNS, as an A record for "fs" like and point it to your public IP address.

Installing ADFS

First we create an A record on the internal DNS server. Next we install ADFS from server manager. Import the certificate and assign it to the https binding.
  • Create a CNAME record on the Domain Controler. This is so that the ADFS server can be resolved internally. (create and point to your
  • On the ADFS server to be:Install the Federation Services Role from server manager. IIS will be installed too.
  • Import the certificate we copied over in the last section.
  • Open IIS, go to the default website and add a HTTPS binding. Select the certificate that was imported.
  • Open the ADFS management console and Create a new "Federated Service".(Stand-Alone). Click through and complete the wizard.

Installing the ADFS Proxy

In the section we install the FS roles on the FS server and the FSProxy server. 
  • On the ADFSProxy server: Install the Federation Services Proxy Role from server manager. IIS will be installed too.
  • Import the certificate we copied over in the last section.
  • Open IIS, go to the default website and add a HTTPS binding. Select the certificate that was imported.
  • Open the ADFS management console and test the connection to the ADFS server. Enter your credentials and finish the wizard.

Adding and Verifying Domains

In this section we install the Online Services Sign-in assistant and the Azure PowerShell module on the DC. We then associate the local domain with out office 365 domain, and then convert it to be a federated domain.
Before you begin, create a 2nd Global Admin in office 365 like "[email protected]". Make sure you create it on the OnMicrosoft domain, and NOT the domain you are going to syncronize - You'll need it in this part.


Also, this first step would normally be done as part of the Azure AD Connect part, but if you try to run the readiness checks after the domain has been converted it just failed miserably. 

  • Log into O365 Admin Panel > Services > Directory Synchronization: Follow the instructions to enable the sync. This wizard will do all the checks on the domain to ensure it is fit for synchronization. This can be done from any domain joined machine. Do NOT Enable Sync at this point just quit once you have ensured the domain is tidy.
  • On the ADFS: Install the Online Services Sign-in assistant
  • On the ADFS: Install the Azure Active Directory PowerShell Module
  • Log into Office 365 Admin Panel, go to domains and "Add a Domain" Follow instructions to verify. 
  • You'll need to log into your Public DNS and configure a TXT record for verification. 
  • Open the Azure Active Directory PS module and run the following commands:
    • Connect-MsolService - Then enter secondary O365 tenant credentials we created above. This is because you'll get an error if you try yo run the next commands while your logged in as an account that will be synced. 
    • Get-MsolDomain - You should see the domain we just added
      • Set-MsolAdfsContext -Computer ADFS.techshizz.local - This command associates the ADFS server with the O365 domain. YOU MUST ENTER THE FQDN OF THE LOCAL ADFS SERVER NOT THE EXTERNAL DNS ADDRESS.
    • For this part I had to log out and log back in on the Enterprise Admin account:  Convert-MsolDomainToFederated -DomainName techshizz.local - This converts the domain to be federated.
    • Get-MsolFederationProperty - DomainName techshizz.local - The output here should confirm the domain has been converted successfully. 
    • Log into the O365 Admin Center > Domains > Select Domain > Click "View DNS Settings". You should see that Single Sign on is Enabled.

Activating Azure AD Connect

  • On the ADFS machine, download and run the Active Directory Synchronization tool (Azure AD Connect). Follow the wizard. Do not use the Express Install, as this will skip the Azure ADFS part. 
  • To start the Sync Manually you can run this PowerShell command:
    • Start-OnlineCoexistanceSync
  • Assign Licences to the newly added users in AD. REMEMBER to set the service location for these users before assigning a licence. 
  • Before SSO works, you need to add your domain into the "Intranet Trusted Sites" list in the client browsers. NOTE: SSO need Internet Explorer to work correctly. This is because Firefox, Google Chrome, and Safari dont support Extended Protection for Authentication; the recommended option is to install and use Internet Explorer 10 or later.
  • Finally I got an error/Warning at the end of Azure AD connect that needs addressing. 

To do this you need to log on to the ADFS server and make sure the Active Directory PowerShell Module is installed and the CMI tools. 

Once thats done you need to run these PowerShell Commands:

Import-Module -Name "C:\Program Files\Microsoft Azure Active Directory Connect\AdPrep\AdSyncPrep.psm1";
$aadAdminCred = Get-Credential;
Initialize-ADSyncDomainJoinedComputerSync –AdConnectorAccount [connector account name] -AzureADCredentials $aadAdminCred;


Azure AD Connect


  • Domain forest functional level must be 2003 or higher
  • For Password Writeback your domain controllers must running 2008 with the latest service pack.
  • For Password synchronization domain controllers must be running 2008 R2 with the latest service pack.
  • Azure AD Connect must be installed on a server running 2008 or later. This can be a domain controller or a member server if you are using express settings. If you use advanced settings, the server can be stand-alone with the exception of using SBS or Windows Server Essentials.
  • If Azure AD Connect is installed on 2008, ensure all of the latest hotfixes are installed from windows update. The installation will not start with an unpatched server.
  • If ADFS is deployed the server running ADFS must be Server 2012 R2 or later with WinRM enabled.
  • If ADFS is being deployed an SSL certificate is required.
Hardware Requirements
The table below shows the minimum requirements for the Azure AD Connect sync computer.
Number of objects in Active DirectoryCPUMemoryHard drive size
Fewer than 10,0001.6 GHz4 GB70 GB
10,000–50,0001.6 GHz4 GB70 GB
50,000–100,0001.6 GHz16 GB100 GB
For 100,000 or more objects the full version of SQL Server is required
100,000–300,0001.6 GHz32 GB300 GB
300,000–600,0001.6 GHz32 GB450 GB
More than 600,0001.6 GHz32 GB500 GB

The minimum requirements for computers running AD FS or Web Application Servers is the following:

  • CPU: Dual core 1.6 GHz or higher
  • MEMORY: 2GB or higher
  • Azure VM: A2 configuration or higher

Software Requirements

If you use a separate SQL Server, then these requirements apply:
  • Azure AD Connect supports all flavors of Microsoft SQL Server from SQL Server 2008 (with SP4) to SQL Server 2014. Microsoft Azure SQL Database is not supported as a database.
  • You must use a case-insensitive SQL collation. These are identified with a _CI_ in their name. It is not supported to use a case-sensitive collation, identified by _CS_ in their name.
  • You can only have one sync engine per database instance. It is not supported to share the database instance with FIM/MIM Sync, DirSync, or Azure AD Sync.