An easy of distinguishing both versions is to look for a PowerShell variable called $psversiontable. If it is not defined, then you are running v1. If it is there, you have v2. You can also look at a registry key to differentiate between v1 and v2: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\PowerShell\1\PowerShellEngine\PowerShellVersion.

Note that if PowerShell was installed as an update package you may not find it under installed software. You may have to look at the update packages. Also note that PowerShell v2 can be installed over v1 without having to uninstall v1 first. If you were running any CTP versions than the install may make you find and manually uninstall v1 first.

Using Get-QADUser cmdlet, you can define the location of all your users using the –searchlevel parameter or you can sweep the whole directory for all user accounts. And then pipe the results to the foreach and use Set-QADuser to fix the display names (in this example) based on the users’ first and last name

Get-QADUser mydomain.int/users -sl 0 | foreach {Set-QADUser $_ -DisplayName ("{0} {1}" -f $_.firstname,$_.lastname)}

The –sl 0 parameter defines the limit of users to 0.

The tombstone lifetime in an Active Directory forest determines how long a deleted object (called a “tombstone”) is retained in Active Directory Domain Services (AD DS). The tombstone lifetime is determined by the value of the tombstoneLifetime attribute on the Directory Service object in the configuration directory partition.

Directory Services veteran and MVP Joe Richards has published a short blog entry demystifying the confusion a technet article has caused in regards to how to go about figuring a TSL on a particular domain. Note that new forests that are installed with Windows Server 2003 with SP1 and up have a default tombstone lifetime of 180 days.

Joe shares his ADFIND tool to lookup the current value of the TSL attribute (irrespective of what OS was used to build the forest). Note that as Joe pointed out if this attribute is not set (i.e empty value) then the TSL is 60 days. Here I show you how to lookup the TSL with PowerShell.

Using Quest cmdlets :

Get-QADbject “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=yourdomain,DC=int” includeallproperties | Select TombstoneLifetime

And with using native AD cmdlets (of ADWS) in Windows Server 2008 R2 :

Get-ADObject -Identity “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=R2,DC=lab” -properties tombstonelifetime

Also within PowerShell, you can also use ADSI to lookup the TSL value.

[ADSI]$config=LDAP://cn=Directory Service,cn=Windows NT,cn=Services,cn=Configuration,DC=R2,dc=lab

$config.TombstoneLifetime

Also, here is how you can use DSQUERY from the Windows Support Tools to lookup the TSL.

dsquery * “CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=R2,DC=lab” -scope base –attr

tombstonelifetime

Note that I have used my test forest’s DN of R2.lab in above examples, be sure to replace the values with your forest’s DN. Above query should be typed in one line.

.

My Windows Server 2008 R2 Server Core has a very small footprint, it is a single processor/20gb hd/512mb ram machine. The first thing you need is the KMS Host key from your Microsoft Volume Licensing site or from your TAM.
The command to register the machine as the KMS host is slmgr /ipk <your key>

Once it is registered, you need to activate the host itself. Run slmgr -ato
You can check the status and brief description of the KMS host by running slmgr –dli

The verbose information is provided via slmgr –dlv

Once KMS is setup, it will register its SRV record in DNS. You can verify from your workstation if it has done so via,

nslookup -type=srv _vlmcs._tcp

From then on clients will automatically be reverted to your KMS host for activation but as hinted in the drawing above, starting with Windows 7 and 08 R2, the minimum threshold (activation attempts/requests) that are needed to fully activate the KMS host is 25 Vista/Windows 7 clients or 5 Server 2008 (R2). This number can comprise of virtual and physical loads, previously this was limited to physical systems only. The slmgr -dlv will show you the total requests received.
Note that the KMS is desgined to let you better manage your internal activation for compliance reason. Micrsoft does not go receive any internal information from between the KMS host and KMS client. KMS has you abide your EA Volume Licenseing, check the VL Product Groups shown in the diagram that are pertinent for your environment. I find the group B to be most commonly required.

Important note : Installing/configuring the KMS does not open up the pertinent firewall port (default port 1688). From running “slmgr -dli” you will notice that it says that the KMS is listening on port 1688 but the rule is not enabled so you may do so like this.

netsh advfirewall>FIREWALL add rule name=”KMS” dir=in action=allow protocol=tcp
localport=1688
Ok.

For more information see this link.

VMware time setting from the VMware tools within the VM:

Or under the VM settings from VIC :

Hyper-V setting from the VM settings :

A great resource to refer to, to learn how to configure an authoritative time source for your DCs – see this KB http://support.microsoft.com/kb/816042

Cache locking is a new security feature available with Windows Server® 2008 R2 that allows you to control whether or not information in the DNS cache can be overwritten. When a recursive DNS server responds to a query, it will cache the results obtained so that it can respond quickly if it receives another query requesting the same information. The period of time the DNS server will keep information in its cache is determined by the Time to Live (TTL) value for a resource record. Until the TTL period expires, information in the cache might be overwritten if updated information about that resource record is received. If an attacker successfully overwrites information in the cache, they might be able to redirect traffic on your network to a malicious site.

Cache locking is configured as a percent value. For example, if the cache locking value is set to 50, then the DNS server will not overwrite a cached entry for half of the duration of the TTL. By default, the cache locking percent value is 100. This means that cached entries will not be overwritten for the entire duration of the TTL. The cache locking value is stored in the CacheLockingPercent registry key. If the registry key is not present, then the DNS server will use the default cache locking value of 100.

You can configure the CacheLocking with DNSCMD utility from the command line (launched under elevated rights).

dnscmd /Config /CacheLockingPercent <percent>

You may also check the current percentage set for this setting with the /info switch of DNSCMD.

With above, the pertinent DWORD registry key is created under HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\DNS\Parameters

However, in real world you push down this registry key via Group Policy Preferences to all your DNS servers. Values for the key are shown below.

You may also use this to export this data to a CSV file. Notice that when using the export-csv cmdlet you must choose the ‘select’ and define the attributes that should be exported. Format-Table (aliased above as FT) is used to display the information on the console.

GetQADUser-sizelimit 0 | where{$_.whencreated -gt (get-date).adddays(-90)}| select Name,WhenCreated,DN | Export-csv c:\Users90days.csv

There is always a couple of ways to accomplish the same task with further fine tuning your query. As you can see that above query would grab all the users in the domain, going by their whenCreated attribute and present you the pertinent users.

You can define the OU to search with the –searchroot parameter.

Get-QADUser –Searchroot ‘test.mydomain.int/Users/Chicago/’ | where{$_.whencreated -gt (get-date).adddays(-90)}

Alternatively, if you would to like find users account that have been modified since x number of days, you can try something like this.

$OU = <OU PATH>
Get-QADUser -LastChangedAfter (get-date).adddays(-7) -search $OU -sl 0 | ft name,whenchanged

You can download the 44×24in poster from here

$old=(get-date).adddays(-30)

Get-QADUser -SearchRoot ‘mydomain.int/users’ -Name “*$*” -IncludedProperties pwdlastset | where {$_.pwdlastset –gt $old}

You may also sort and view the results as below

Any trusts that have not reset their passwords in last 30 days are probably no longer valid. If you are using ADWS on Windows Server 2008 R2, then something like below should suffice, assuming you have already created the $old variable using the same command as above.

Get-ADUser -Filter ‘Name -like “*$*”‘ -Properties pwdlastset | where {$_.pwdlastset –gt $old}