Archive | Powershell RSS for this section

How to install server GUI on Windows Server 2016 from PowerShell

 

As you probably know, Microsoft Windows Server 2016 Technical Preview 3 has been released and you can get it from Microsoft Technet Evaluation center for free.

You can install server system with or without GUI, you have two choices:

  • install core edition

Windows Server 2016 Technical Preview 3

  • install server with GUI

Windows Server 2016 Technical Preview 3 – Server with Desktop Experience

Windows Server 2016 installation type

Windows Server 2016 installation type

if you choose the second installation option, that’s all in this case. After server OS installation you will get Windows Server desktop with complete GUI.

What if you decided to install full core edition and after some time you don’t want to use it anymore. There is an option to use PowerShell and install missing features to have full server with GUI. This time with Windows Server 2016 it is not so simple as it was in Windows Server 2012/2012R2.

When you try to install missing feature from PowerShell console and your server has no access to the Internet, installation fails!

This happens because from Windows Server 2016, GUI features are removed from installation image and you cannot simply activate them to turn on/off core edition.

Open PowerShell console and search for features name to install

Get-WindowsFeature -Name *GUI*
Get-WindowsFeature PowerShell cmd-let

Get-WindowsFeature PowerShell cmd-let

in “Install state” column you will see that features state is “removed”.

If you simply try to install these features and your server has no access to the Internet or installation source is not defined by Group Policy, operation will fail. This is highly possible that your server has no access to the Internet and if this is the first Windows Server 2016 installation, you would probably not have central location where shared components for this system are available.

In case where your server has access to the Internet, simply type in PowerShell console this syntax and wait couple of minutes

Install-WindowsFeature -Name Server-Gui-Shell,Server-Gui-Mgmt-Infra
Install-WindowsFeature PowerShell cmd-let

Install-WindowsFeature PowerShell cmd-let

but if you have no access to the Internet, you will see similar error in the console

Error during Windows feature installation

Error during Windows feature installation

then you have to use your installation media to successfully install server GUI features. Before you can do that, you need to identify appropriate index of Windows Server 2016 edition from which you want to install features. They are only available in full editions, so you need to skip indexes for core editions in the list. To get information of available editions in install.wim installation file, you need to use below PowerShell cmd-let

Get-WindowsImage -ImagePath d:\sources\install.wim

where d:\ is a letter of you drive with installation media

install.wim Windows Server 2016 editions and their index

install.wim Windows Server 2016 editions and their index

Check index number for Standard of Datacenter edition and remember it. As you can see in the screen above, appropriate image index is 2 or 4

In these images, all required features are available and they can be used as a source of installation.

To install feature from non-default location, you need to specify -Source switch to Install-WindowsFeature cmd-let. The switch requires appropriate syntax

InstallationProvider:WIMFileLocation:ImageIndex

wim:d:\sources\install.wim:2

or

wim:d:\sources\install.wim:4

the full installation syntax is available below

Install-WindowsFeature -Name Server-Gui-Shell,Server-Gui-Mgmt-Infra -Source wim:d:\sources\install.wim:2
Install-WindowsFeature cmd-let with -Source switch

Install-WindowsFeature cmd-let with -Source switch

and now, you installation should succeed even if your server does not have an access to the Internet

Windows feature installation progress

Windows feature installation progress

after some time, you would be prompted to reboot the server to apply the changes

Prompt for server restart

Prompt for server restart

use PowerShell cmd-let to restart server and wait couple of minutes to apply changes

Restart-Computer
Restarting server

Restarting server

when server is booting you should see on the screen features configuration

Feature configuration at server's startup

Feature configuration at server’s startup

when it is done, you should see logon screen

Log in into Windows Server 2016

Log in into Windows Server 2016

Provide appropriate credentials and check if you can see desktop

Server GUI in Windows Server 2016

Server GUI in Windows Server 2016

If you are able to see START tile and other desktop features, congratulations. Everything is configured properly. You can do whatever you want with your server, now.

 

Author: Krzysztof Pytko

iSiek’s forum has been launched

 

I would like to announce you that iSiek’s forum about Microsoft Windows services has been launched!

iSiek's forum

iSiek’s forum

I hope you would participate in building new IT community on this forum. I hope we would be able to help each other.

You are invited! I encourage you to register your account for free and start posting your issues or try to help others.

Just some simple forum’s rules

  1. Forum is free of charge. It is maintained from ads.
  2. To contribute in community, free registration is required
  3. Write posts in English
  4. Check forums if similar problem does not exist
  5. Use appropriate forum to post issue
  6. Do not spam
  7. Use external services to attach images/logs and place only link to them
  8. Be polite and do not use vulgarism
  9. If you do not want to help, do not answer

Be a part of this new community and make family atmosphere here.

I hope we will make this IT world better!

Forum address is http://kpytko.pl/forum

Author: Krzysztof Pytko

Seizing FSMO roles with PowerShell

 

I wrote some time ago an article about Seizing FSMO roles. That was a little bit painful method and it required to use ntdsutil command which is inconvenient in use. Especially for unexperienced administrators.

Now, when Microsoft released PowerShell 3.0 with Windows 8 Remote Server Adminisration Tools and Windows Server 2012 we have new Active Directory module for PowerShell. It allows to use dedicated PowerShell cmd-let for that.

When your Domain Controller holding any FSMO role is down and cannot be brought up again you need to seize that/there role(s) to the new one.

You would be able to use PowerShell cmd-let

Move-ADDirectoryServerOperationMasterRole

Hey, this exactly the same cmd-let as for transferring FSMO roles, am I right? Yes, you are. The only one difference is that you have to specify at the end of the cmd-let -Force switch which tells that role must be seized not transferred!

Of course to be able to use this feature some prerequisites are required:

  • At least one Windows Server 2008R2 Domain Controller
  • Access to Active Directory Web Services (9389/tcp port unblocked)
  • Server or client machine with PowerShell 3.0 or newer
  • Imported PowerShell 2.0  or newer module for Active Directory

 To get an overview of this command let’s see its help by typing

Get-Help Move-ADDirectoryServerOperationsMasterRole
Move-ADDirectoryServerOperationMasterRole help

Move-ADDirectoryServerOperationMasterRole help

In this case 3 parameters are required:

  • target Domain Controller name
  • FSMO role(s) name to seize
  • -Force switch

Important! When you are seizing any FSMO role, you need to know that Domain Controller which held this role previously, cannot be brought up on-line! This machine may be reused, but first it must be reinstalled!

To get an overview of transferring FSMO roles with PowerShell please read an article on my blog showing how to do that. The article is available at this link.

You are allowed to seize one specific FSMO role or set of FSMO roles. This can be done once as this operation requires old Domain Controlller reinstallation. please be aware of that, there is no place for mistake! 🙂

Seizing specific FSMO role

Active Directory contains five unique FSMO roles:

  • Schema Master
  • Domain Naming Master
  • PDC Emulator Master
  • RID Master
  • Infrastructure Master

if any of these roles where held by your broken Domain Controller, you need to seize it to the new one. Just do this like you would be transferring them but at the end of cmd-let place -Force switch

Move-ADDirectoryServerOperationMasterRole -Identity <TargetDomainController> -OperationMasterRole <FSMORoleName> -Force

this will seize specified operation master role to selected Domain Controller. It would take some time as cmd-let tries to connect to the previous DC and check if there is possible role transfer instead of seize.

Move-ADDirectoryServerOperationMasterRole -Identity DC01 -OperationMasterRole InfrastructureMaster -Force

 Seizing specified FSMO role

Seizing specified FSMO role

to seize other role than this one, replace its name with  one of those below

  • SchemaMaster
  • DomainNamingMaster
  • PDCEmulator
  • RIDMaster
  • InfrastructureMaster

Information! When you transfer PDC Emulator role, you need to remember that you should introduce new time server within your environment. If you wish, you may follow steps described in the article on my blog at Advertising new time server in domain environment

and remember, when you are seizing any FSMO role, you need to know that Domain Controller which held this role previously, cannot be brought up on-line! This machine may be reused, but first it must be reinstalled!

Seizing set of FSMO roles

This works exactly the same way as for transferring FSMO roles. You just need to specify operation master role name(s) separated by comma (,) and put -Force switch at the end. All provided FSMO roles will be seized to the selected Domain Controller.

To seize roles use below syntax

Move-ADDirectoryServerOperationMasterRole -Identity <TargetDomainControllerName> -OperationMasterRole <FSMORoleName1>, <FSMORoleName2>, ...<FSMORoleNameN> -Force

and these operation master roles will be seized.

Commonly used scenarios are related with seizing forest-wide, domain-wide or all FSMO roles. Let’s see  how to do that

Seizing forest-wide FSMO roles:

Move-ADDirectoryServerOperationMasterRole -Identity DC01 -OperationMasterRole SchemaMaster, DomainNamingMaster -Force

Seizing domain-wide FSMO roles:

Move-ADDirectoryServerOperationMasterRole -Identity DC01 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster -Force

Seizing all FSMO roles:

Move-ADDirectoryServerOperationMasterRole -Identity DC01 -OperationMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster -Force
Seizing all FSMO roles

Seizing all FSMO roles

It would take some time as cmd-let tries to connect to the previous DC and check if there is possible roles transfer instead of seize.

Information! When you transfer PDC Emulator role, you need to remember that you should introduce new time server within your environment. If you wish, you may follow steps described in the article on my blog at Advertising new time server in domain environment

and remember, when you are seizing any FSMO role, you need to know that Domain Controller which held this role previously, cannot be brought up on-line! This machine may be reused, but first it must be reinstalled!

To verify if operation master roles were seized to selected Domain Controller, execute

for forest-wide FSMO roles:

Get-ADForest | Select SchemaMaster, DomainNamingMaster | Format-List
Veryfying forest-wide FSMO roles

Veryfying forest-wide FSMO roles

and for domain-wide FSMO roles use this one:

Get-ADDomain | Select PDCEmulator, RIDMaster, InfrastructureMaster | Format-List
Veryfying domain-wide FSMO roles

Veryfying domain-wide FSMO roles

At the end, you should do metadata cleanup for that broken Domain Contoller, and that’s all!

If you wish you may follow other articles on my blog, showing how to do metadata cleanup of broken Domain Controller

Author: Krzysztof Pytko

Transferring FSMO roles with PowerShell

 

Some time ago, I introduced on my blog two articles about

and

They are still valid but some new options appeared when Windows Server 2012 and PowerShell 3.0 were released.

From now, you can simply use PowerShell cmd-lets to do that very quick and simple. This not requires any snap-ins registration on a server or machine, just simply run PowerShell and execute dedicated cmd-let with appropriate syntax.

Of course to be able to use this feature some prerequisites are required:

  • At least one Windows Server 2008R2 Domain Controller
  • Access to Active Directory Web Services (9389/tcp port unblocked)
  • Server or client machine with PowerShell 3.0 or newer
  • Imported PowerShell 2.0  or newer module for Active Directory

If above prerequisites are met, you can use this cmd-let

Move-ADDirectoryServerOperationMasterRole

its name is really long but don’t worry it is really simple in use.

To get an overview of this command let’s see its help by typing

Get-Help Move-ADDirectoryServerOperationsMasterRole
Move-ADDirectoryServerOperationMasterRole help

Move-ADDirectoryServerOperationMasterRole help

as you can see, there are two parameters required to successfully initiate FSMO roles transfer

  • target Domain Controller name
  • FSMO role(s) name

 Active Directory contains five unique operation master roles.

Two from them are unique at forest level

  • Schema Master
  • Domain Naming Master

to check where they are currently located, you need to use Get-ADForest cmd-let

Get-ADForest | Select SchemaMaster, DomainNamingMaster | Format-List

You will get a list of server(s) which hold forest-wide FSMO roles

List of forest-wide FSMO roles

List of forest-wide FSMO roles

and three are unique at domain level. That means, every domain in the forest has its own set of FSMO roles. These roles are:

  • PDC Emulator
  • RID Master
  • Infrastructure Master

to check where they are currently located, you need to use Get-ADDomain cmd-let

Get-ADDomain | Select PDCEmulator, RIDMaster, InfrastructureMaster | Format-List
List of domain-wide FSMO roles

List of domain-wide FSMO roles

In case you have multiple domains and you would like to check FSMO roles location there, you need to specify -Server switch and put there DNS domain name which you want to check

Get-ADDomain -Server testenv.devel | Select PDCEmulator, RIDMaster, InfrastructureMaster | Format-List
List of FSMO roles for selected domain

List of FSMO roles for selected domain

Note! Global Catalog is a Domain Controller role not Operation Master role!

To start transferring Operation Master roles to other Domain Controller, you need to specify role name within -OperationMasterRole switch.

Available role names are:

  • SchemaMaster
  • DomainNamingMaster
  • PDCEmulator
  • RIDMaster
  • InfrastructureMaster

all you have to do is put single role name or multiple role names separated by comma (,), in example:

-OperationMasterRole PDCEmulator

or

-OperationMasterRole SchemaMaster, DomainNamingMaster

specified role(s) would be transferred to other Domain Controller.  Hey, but which one? You need to put DC’s name under -Identity switch.

General syntax for that is:

Move-ADDirectoryServerOperationMasterRole -Identity <DomainControllerName> -OperationMasterRole <FSMORoleName>

An example for transfer Infrastructure Master operation master role is:

Move-ADDirectoryServerOperationMasterRole -Identity DC06 -OperationMasterRole InfrastructureMaster

You need to confirm operation by answering “Y yes” or “A yes to all” to the question, and role(s) are transferring.

Transferring single FSMO role

Transferring single FSMO role

To transfer more than one FSMO role in single run, you need to put FSMO roles separated by comma (,) sign

Move-ADDirectoryServerOperationMasterRole -Identity <DomainControllerName> -OperationMasterRole <FSMORoleName1>,<FSMORoleName2>,..<FSMORoleNameN>

Let’s see cmd-let full syntax for transferring InfrastructureMaster and RID Master

Move-ADDirectoryServerOperationMasterRole -Identity DC06 -OperationMasterRole InfrastructureMaster, RIDMaster

Press “A yes to all” and you do not have to confirm every transferring role separately

Transferring multiple FSMO roles

Transferring multiple FSMO roles

OK, so let’s see 4 commonly used actions in productive environments:

  • transferring single FSMO role
  • transferring forest-wide FSMO roles
  • transferring domain-wide FSMO role
  • transferring all FSMO roles

Transferring single FSMO role

As it was shown above, you need to only know to which Domain Controller are you going to migrate the role and its name. So, below syntax may be used in this case

Move-ADDirectoryServerOperationMasterRole -Identity DC06 -OperationMasterRole InfrastructureMaster
Transferring single FSMO role

Transferring single FSMO role

Just replace InfrastructureMaster role name with this one you would like to transfer and that’s all.

Information! When you transfer PDC Emulator role, you need to remember that you should introduce new time server within your environment. If you wish, you may follow steps described in the article on my blog at Advertising new time server in domain environment

Transferring forest-wide FSMO roles

As it was introduced above, there are 2 forest-wide roles:

  • Schema Master
  • Domain Naming Master

to transfer them, use this below’s simple command specifying target Domain Contoller’s name and forest-wide role names

Move-ADDirectoryServerOperationMasterRole -Identity DC06 -OperationMasterRole SchemaMaster, DomainNamingMaster
Transferring forest-wide FSMO roles

Transferring forest-wide FSMO roles

and your forest-wide roles are transferred!

Transferring domain-wide FSMO role

You also know these roles, they were introduced above and there are 3 domain-wide FSMO roles:

  • PDC Emulator Master
  • RID Master
  • Infrastructure Master

to transfer them, use this below’s simple command specifying target Domain Contoller’s name and domain-wide role names

Move-ADDirectoryServerOperationMasterRole -Identity DC06 -OperationMasterRole PDCEmulator, RIDMaster, InfrastructureMaster
Transferring domain-wide FSMO roles

Transferring domain-wide FSMO roles

and they are transferred!

Information! When you transfer PDC Emulator role, you need to remember that you should introduce new time server within your environment. If you wish, you may follow steps described in the article on my blog at Advertising new time server in domain environment

Transferring all FSMO roles

You know all FSMO roles, so you may wish to transfer them all from the old Domain Controller to the new one. Below syntax does it smoothly

Move-ADDirectoryServerOperationMasterRole -Identity DC06 -OperationsMasterRole SchemaMaster, DomainNamingMaster, PDCEmulator, RIDMaster, InfrastructureMaster
Transferring all FSMO roles

Transferring all FSMO roles

and voila! All FSMO roles are transferred!

Information! When you transfer PDC Emulator role, you need to remember that you should introduce new time server within your environment. If you wish, you may follow steps described in the article on my blog at Advertising new time server in domain environment

Well done! You have already transferred all your FSMO rles to the other Domain Controller.

Author: Krzysztof Pytko

Active Directory reporting – version 2

 

It took me some time to publish this post but finally, I did it.

My previous post about Active Directory Reporting using PowerShell script was published almost one year ago! Since that time a lot of new features were implemented within the script.

I was in contact with Daniel Petri, he suggested a lot of new features and we added them to the script. You may also wish to visit his great blog at  http://www.petri.com/

Today, I would like to introduce this script to you. I hope it would be useful for many of you. Let’s start with its description.

Have you ever consider how to simplify an Active Directory reporting for new AD environments? I decided to prepare PowerShell script which check a lot of Active Directory configuration settings and brings them on screen. This option reduces time required to gather some basic and a little bit more advanced information about Active Directory forest and domain(s) configuration.

AD environments mostly have at least one Windows Server 2008 R2 Domain Controller where Active Directory Web Services are running. This is mandatory prerequisite to be able to execute the script.

You can simply execute it on:

  • Domain Controller
  • Domain member server with PowerShell 2.0 installed
  • Domain member workstation with RSAT installed

for domain member machines you need to be sure that Active Directory Web Services port in available from location where you are running. By default it is 9389/tcp

The script requires only authenticated domain user to work properly if no custom delegation control is configured.

You can simply run it within PowerShell console without any parameter and its start scanning currently logged on forest with all its domain. When you specify a parameter – it must be DNS forest name – the scan is performed for the specified forest.

You don’t have to worry when executing the script because this is run in read-only mode, so no changes are done in the environment.

Below you may find some screen-shots from the script execution. This comes from multi-site, single domain test environment.

The output color (red) related with scanned data does not refer to an error! This is only to emphasise the setting on which you should pay attention.

Let’s see what settings are being checked when script is executed.

At forest level:

  • Forest name
  • Schema version
  • Forest Functional Level
  • List of trusts
  • Active Directory Recycle Bin enablement
  • Check of Exchange version
  • Check of Exchange Organization name
  • Check of Lync version
  • Tombstone lifetime period
  • Enumerate all partitions
  • All domains in the forest
  • Global Catalog servers in the entire forest
  • Site and Subnets information
  • Site link(s) configuration
  • UPN suffixes
  • Forest FSMO roles holders
  • Check members for Enterprise and Schema Administrator groups
  • Domain Controller(s) details
  • SYSVOL replication method
  • SYSVOL size for DFS-R replication method

at domain level:

  • Domain name
  • NetBIOS domain name
  • Domain Functional Level
  • List of Domain Controllers
  • List of Read-Only Domain Controllers
  • Global Catalog servers for the domain
  • SYSVOL replication method
  • Orphaned objects check
  • Lingering objects check
  • Conflict replication objects check
  • Default domain computer objects location
  • Default domain user objects location
  • Total no. of Organizational Units
  • Total no. of computers
  • Total no. of computers with particular operating system version
  • Total no. of users
  • Active users
  • Inactive users
  • Locked out users
  • Users with no password required
  • Users with password never expires
  • Total no. of groups
  • Global, Universal and Local groups check
  • Check for existance of default domain policies
  • Total no. of Domain Administrators
  • Built-in Domain Administrator account details
  • Domain FSMO roles holders
  • Default Domain Password policy details
  • Total no. of Fine-Grained Password Policies

So, please take a look at the screen-shot output from multi-site single domain environment below

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

and at this moment, that’s all. I hope in the future the script would be developed. I am going to add the results export into formatted HTML format.

Or maybe, you would like to participate with its future development? If so, please let me know and we’ll do that!

OK, and this is a script which you can download. After downloading, please remove –v2.doc extension and leave only .ps1

Active Directory Reporting v0.2 script

Author: Krzysztof Pytko

Active Directory reporting

 

Have you ever consider how to simplify an Active Directory reporting for new AD environments? I have recently played with new multi domain environment and I had to check many things manually with built-in consoles. This is nothing difficult but needs some time and when I have done the environment recognition, I decided to prepare PowerShell script. It reduces time required to get some basics information about Active Directory forest and domain(s) configuration.

Today, many Active Directory environments have at least one Windows Server 2008 R2 Domain Controller where Active Directory Web Services are running. The script is written for at least PowerShell 2.0 with Active Directory module.

You can simply run it within PowerShell console without any parameter and its start scanning currently logged on forest with all its domain. When you specify a parameter – it must be DNS forest name – the scan is performed for the specified forest.

You don’t have to worry when executing the script because this is run in read-only mode, so no changes are done in the environment.

Below you may find some screen-shots from the script execution. Unfortunately, I have only access to single forest, single domain enviropnment at this time and you will get short overview of the script. But i will try to put additional screen-shots from multi-domain environment in the nearest future.

Oh, and one more thing. The output color (red) related with scanned data does not refer to an error! This is only to emphasise the setting on which you should pay attention.

That’s all, let’s see how the results are looking.

Script executed without a parameter

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

and script execution with forest name as a parameter

Script execution screen-shot

Script execution screen-shot

unfortunatelly, the output is exactly the same as for previous execution but I will replace screen-shots as soon as I will do thet in my multi-domain test environment.

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

OK, what is scanned by the script? Just take a look at the list below

At the forest level:

  • Forest name
  • Schema version
  • Forest Functional Level
  • Active DIrectory Recycle Bin enablement
  • All domains in the forest
  • Site names
  • Global Catalog servers in the entire forest
  • UPN suffixes
  • Forest FSMO roles holders

At domain level (each domain):

  • Domain name
  • NetBIOS domain name
  • Domain Functional Level
  • List of Domain Controllers
  • List of Read-Only Domain Controllers
  • Global Catalog servers for the domain
  • Default domain computer objects location
  • Default domain user objects location
  • Total no. of Organizational Units
  • Total no. of computers
  • Total no. of users
  • Total no. of groups
  • Total no. of Domain Administrators
  • Built-in Domain Administrator account details
  • Domain FSMO roles holders
  • Default Domain Password policy details
  • Total no. of Fine-Grained Password Policies

 

UPDATE

 

It took me some time to update this post but finally, I did it. A lot of new features were added into script check.

I was in contact with Daniel Petri, he suggested a lot of new features and we added them to the script. You may also wish to visit his great blog at  http://www.petri.com/

Please take a look at new features on forest level, implemented in the new script version:

  • List of trusts
  • Check of Exchange version
  • Check of Exchange Organization name
  • Check of Lync version
  • Tombstone lifetime period
  • Enumerate all partitions
  • Site and Subnets information
  • Site link(s) configuration
  • Check members for Enterprise and Schema Administrator groups
  • Domain Controller(s) details
  • SYSVOL replication method
  • SYSVOL size for DFS-R replication method

Also new features at domain level were added:

  • SYSVOL replication method
  • Orphaned objects check
  • Lingering objects check
  • Conflict replication objects check
  • Total number of computers with particular operating system version
  • Active users
  • Inactive users
  • Locked out users
  • Users with no password required
  • Users with password never expires
  • Global, Universal and Local groups check
  • Check for existance of default domain policies

So, please take a look at the output from multi-site single domain environment below

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

Script execution screen-shot

and at this moment, that’s all. I hope in the future the script would be developed. I am going to add the results export into formatted HTML format.

Or maybe, you would like to participate with its future development? If so, please let me know and we’ll do that!

OK, and this is a script which you can download. After downloading, please remove –v2.doc extension and leave only .ps1

Active Directory Reporting v0.2 script

Author: Krzysztof Pytko

Fine-Grained Password Policy in Windows Server 2008/2008R2

 

Recently, I have seen that some administrators afraid of using Fine-Grained Password Policy.It looks like the main reason is they do not know how to set up and how to manage it. I will try to show you some easy steps to understand that and implement in your Active Directory environment.

First of all, if you wish to implement Fine-Grained Password Policy (FGPP) in your environment, your Domain Functional Level must operate at Windows Server 2008 mode. That means, all of your Domain Controllers in a domains must be ran at least on Windows Server 2008. No previous operating systems may be used for DCs. Of course, all the rest domain member servers may be ran on earlier OS versions.

For more details about Domain Functional Level, please read my article on this blog.

OK, so what is FGPP and why we want to use it? As you remember in Windows 2000 Server and Windows Server 2003 we were able only to use single password policy defined at domain level over GPO. There were no possibility to use more than one domain password policy using group policies. When some department in our enterprise required another password policy, we needed to decide if we want to:

  • convince it to use the standard password policy 🙂
  • configure child domain and migrate their objects
  • use 3rd party tools

For more details about Default Domain Password policy, please check an article on my blog for that.

This situation did not change in Windows Server 2008, you can still use only one domain password policy configured in GPO. However, Microsoft introduced new feature to define additional password policies. The policy allows you to define separate password settings for user of group of users.

Important! Fine-Grained Password Policy may be only assigned to user or security global group not to domain or OU

When your DFL is set up at appropriate level, you can start using Fine-Grained Password Policy feature. What do you need to know about this kind of Password Settings Object (PSO) before you will set it up:

  • you can apply it only to user or security global group
  • you can set it up using ADSI Edit
  • you can set it up using PowerShell module for Active Directory
  • you need to use dsget command to verify if policy is applied
  • you can use PowerShell to manage PSO
  • only one password set applies to user or group

Using Fine-Grained Password policy, you overwrite default domain policy for user or group of users. However, you need to know that you may apply as many FGPPs as you wish but the only one will be applied. There are few important things to know about password policy precedence:

  • when applied more than one to a group then PSO with the lowest precedence index is applied
  • when applied more than one to a user then PSO with the lowest precedence index is applied
  • when applied more than one to a user or a group then PSO on user level is applied
  • when user is a member of few groups with PSO assigned then policy with the lowest precedence index is applied

Now, when we know those things, we can start creating our first Fine-Grained Password Policy.

ADSI Edit

ADSI Edit allows you to use GUI method for PSO creation. To start the process, run ADSI Edit from “Administrative Tools” or type in run box: adsiedit.msc

Running ADSIEdit console

When you ran that console, you need to connect to Deafult Naming Context where those objects are stored. To do that, click on root “ADSI Edit” node in a console by right mouse button and choose “Connect to

Connecting to Default Naming Context

Now, in “Connection Settings” window please ensure if in “Select a well known Naming Context area you have pointed to Default Naming Context

Connecting to Default Naming Context

When you are connected to that Naming Context, you need to navigate to a container where you can create PSO. The location of this container is in

CN=Password Settings Container,CN=System,DC=domain,DC=local

Below you can see that container location in ADSI Edit console

PSO container location

In this place you need to create new object by clicking right mouse button and selecting “New -> object”

Creating new Fine-Grained Password Policy

Create object which is responsible for password settings “msDS-PasswordSettings“. From now, you are defining new password policy. Proceed below steps to successfully finish PSO creation process.

Selecting object class

At this step, you need to define Fine-Grained Password Policy name which would be easy to identify by you when you start reviewing PSO list

Creating new PSO object

Now, you need to set up integer value of precedence index. Remember, when any PSO would be in conflict then password policy with the lowest precedence index is being applied

Creating new PSO object

This time, you need to specify if you want to use reversible encryption for passwords. This will store password in plain text, so this is vulnerability for the environment. Do not use this option if any of your legacy application requires that. For this setting you can only use one of two possibilities for boolean variable:

  • true to enable reversible encryption policy
  • false to disable reversible encryption policy

Creating new PSO object

Define how many previous passwords are remembered and user cannot re-use them. This value should be an integer number

Creating new PSO object

OK, at this time, you need to define if user’s password must be complex using 3 out of 4 character categories. When you use true value then, password must meet the complexity using 3 characters group out of 4 available:

  • small letters [a-z]
  • capital letters [A-Z]
  • digits [0-9]
  • special characters [!@#$%^&*()]

in case that yo do not want to force users using complex passwords, you need to put false value in a form. In this example, we would like to use complex passwords

Creating new PSO object

User’s password requires minimum number of characters needed to build good and invulnerable password. You need to define the lowest number of characters to build the password by user. This value is an integer number

Creating new PSO object

Really important part of each password policy is setting for the minimum password age. That means, when user is able to change his/her password after the latest change. When you set this up to short time or disable it, user may change his/her password few times and then he/she is able to use that previous password(s) again. The important part during setting up PSO is to remember that this setting uses non integer variable! Expected value is duration which defines a time in format

d:hh:mm:ss

where

  • d means, how many days
  • hh means, how many hours
  • mm means, how many minutes
  • ss means, how many seconds

an example duration for password which may be changed again after 3 days

3:00:00:00

Creating new PSO object

the next setting determine when user is forced to change the current password. You need to set up time after which password is required to change. This value is also in the same format as the previous one, so you need to use duration format as this is shown in the above step

Creating new PSO object

And now, another part of setting password policy. You need to decide if you wish to enable account lockout or not. However, this is good practice to enable account lockout policy to prevent users guessing password of other users in your environment or prevent hackers from guessing password of your users. Just define integer value for the policy and after entered number of failed logon attempts, the account is being blocked

Creating new PSO object

When you defined after how many failed logon attempts, user account is locked you are able to define 2 other policies related with the previous one. Lockout Observation Window in which you define when user may try to log on once again to the system. After that time, user is able to try once again (but only one chance) log on to the system. If he/she remembers a password and account was locked out by mistake, the next try would be successful. If user does not remember the password, after the next wrong attempt, the account would be locked again for time specified in Lockout Observation Window. This option allows an administrator to tell the users that if they remember password but they locked the account by mistake, they need to wait specified time and try once again. In other case, they should request a password reset. For that setting you need to use again duration variable format like for minimum and maximum password age.

Creating new PSO object

The second policy related with account lockout is Lockout Durationwhich determines the time when user account is completely unlocked. Then user has again defined number of tries to log on to the system. As for the previous setting, it also uses duration format to define time

Creating new PSO object

That was the last setting in PSO wizard. However, remember that when you close it by clicking on “Finish” button, you have only create password policy but it is not applied to any group or user. If you wish to define that at this step, click on “More Attributes” button and from “Select a property to view” drop down box choose “msDS-PSOAppliesTo

Creating new PSO object

Creating new PSO object

When you choose that attribute, you need to define distinguished name of an object to which you want to apply policy. This requires from you to know that DN name to put it in that field in format:

CN=Object Name,OU=OU Location,DC=domain,DC=local

and press “Add” button to add the object to password policy

Creating new PSO object

You can see all objects assigned to PSO in the “Value(s)” list

Creating new PSO object

Above step in PSO wizard requires from you object’s DN to know. What if you do not know it or this DN is really long? You may simply finish a wizard without defining value for msDS-PSOAppliesToattribute. This may be done later in some short and more convenient way. Just take a look for below steps.

When you finish a wizard, you will see new password policy in a selected container. Just edit it by double click on it in ADSI Edit window.

Edit existing PSO

In the “Attribute Editor” list search for msDS-PSOAppliesToattribute and click “Edit” button

Edit existing PSO

Now, you have 2 options for object(s) assigning. Classic window for distinguished name of an object

Edit existing PSO

Edit existing PSO

or just use more familiar option to search an object from AD

Edit existing PSO

Edit existing PSO

OK, when we have created granular password policy and we applied it to some object, how to see if the user is really using that policy? You can use for that dsget command or dsquery and dsget commands combination. Let’s see, how to check if PSO is applied to a user name iSiek

dsquery user -samid iSiek | dsget user -effectivepso

After running this query, you will see information about used PSO policy. If result is empty then you can be sure that user has no Fine-Grained Password Policy assigned and he/she uses default domain password policy

Effective password policy applied to the user

This is working fine as you can see! If you really need different password policies in your environment, I really encourage you to use Fine-Grained Password policy feature as it is really great feature!

PowerShell module for Active Directory

As we already know something more about Fine-Grained Password policy requirements, now we can check how to simply create and apply PSO to an object. For that we need to use PowerShell module for Active Directory. To initiate it run in PowerShell window

Import-Module ActiveDirectory

PowerShell – importing AD module

and wait for cmd-lets to be imported. Now, you can use some PowerShell cmd-lets to manage PSO, let’s see their names. Type in PS window

Get-Help *-ADFine*

Getting cmd-lets for Fine-Grained Password Policy

To create new granular password policy we need to use New-ADFineGrainedPasswordPolicy cmd-let. We need to define all interesting us values as we did it using ADSI Edit. When you skip any value then default settings for that value is being used.

Let’s see how to create another PSO using the same values as in the previous example but over PowerShell cmd-let

New-ADFineGrainedPasswordPolicy -Name it-security-PSO-02 `
-DisplayName it-security-PSO-02 `
-Precedence 200 `
-ComplexityEnabled $true `
-ReversibleEncryptionEnabled $false `
-PasswordHistoryCount 10 `
-MinPasswordLength 8 `
-MinPasswordAge 3.00:00:00 `
-MaxPasswordAge 30.00:00:00 `
-LockoutThreshold 3 `
-LockoutObservationWindow 0.00:25:00 `
-LockoutDuration 0.00:30:00

PowerShell – PSO creation

PSO list

As you can see, PowerShell created new PSO but it is not assigned to any object. We need to use another cmd-let to accomplish that. This cmd-let is Add-ADFineGrainedPasswordPolicySubject

This time, I will assign granular password policy to the user directly.

Add-ADFineGrainedPasswordPolicySubject -Identity it-security-PSO-02 -Subjects iSiek

Assigning PSO to an object

Now, it’s time to verify if PSO is applied to a user. For that you need to use Get-ADFineGrainedPasswordPolicy cmd-let

Get-ADFineGrainedPasswordPolicy -Filter { name -like 'it-security-PSO-02' }

PSO applies to

and that’s all about configuring and setting up Fine-Grained Password Policy objects. You may also check the rest cmd-lets to modify and remove PSO objects.

Author: Krzysztof Pytko

Windows Management Framework 3.0 for Windows Server 2008/2008R2

 

Microsoft has released Windows Management Framework 3.0 for Windows Server 2008/2008R2. You can download it from http://www.microsoft.com/en-us/download/details.aspx?id=34595

This allows you to use Windows Remote Management (WinRM) services, WMI and PowerShell in 3.0 version on Windows Server 2008/2008R2

To be able to run that package, you need to install Microsoft .NET Framework 4 first. Its package is available at http://www.microsoft.com/en-us/download/details.aspx?id=17718

Windows Management Framework 3.0 allows you to use PowerShell in version 3 and manage server over WinRM from new Server Manager on Windows Server 2012 (which required WinRM 3.0)

When you download required packages and install them on a server, you need to enable remote management to allow remote server management. To do that, run in command-line

winrm qc

or

winrm quickconfig

Windows Remote Management configuration

and confirm that you want to enable remote management.

Windows Remote Management configuration

After that, please ensure if all required ports are opened on Windows firewall or just disable required firewall’s profile before you would be able to manage that server over Server Manager in Windows Server 2012 or RSAT in Windows 8

Now, you are able to add those Windows Server 2008/2008R2 into Server Manager and manage them. However, there is one limitation for this kind of management. You cannot install roles/features remotely on Windows Server 2008/2008R2 machines.

Open Server Manager in Windows Server 2012 or RSAT in Windows 8, select “All Servers” on the left side and click right mouse button, choose “Add Servers

Adding Windows Server 2008/2008R2 into Server Manager for remote management

You will see new window where you can select a server to add. You can add servers by one of these criteria:

  • using Active Directory computer object

You can search AD for computers using their

  1. name
  2. OS type
  3. or just display them all and choose from the list

Adding server(s) to Server Manager

  • using existing DNS record
  1. host (A) record – machine name (forward lookup zone)
  2. pointer (PTR) record – machine IP address (reverse lookup zone)

Adding server(s) to Server Manager

  • using text file for import

Adding server(s) to Server Manager

Using one of above methods, add server to Server Manager and we promote it to Domain Controller (select server from the list and click an arrow to add it)

Adding server(s) to Server Manager

and as you can see, server is available on the list (ready to manage)

Windows Server 2008/2008R2 in new Server Manager

From now on, you can manage server(s). Select it on a list, click right mouse button and you will see all available options to manage (except roles/features installation)

Remote server management

Author: Krzysztof Pytko

Determine DFL and FFL using PowerShell

 

I was curious after the last article about checking schema version with PowerShell, if it is possible to use the same template to determine Domain and Forest Functional Levels. I’ve decided to check that using the same code and I found it is also working 🙂

You need to only check different AD objects to get that information.

For Domain Functional Level you need to query Default naming context (domain partition) and read msDS-Behavior-Version attribute. Its value tells you what kind of DFL is present in your domain. However, today, there is no need to check if domain is working in 2000 mixed mode but I decided also to put that information into script to have full overview of DFL. In this case (mixed mode) you have to check ntMixedDomain attribute.

If ntMixedDomain attribute is set to 0  that means Domain Functional Level is not in 2000 mixed mode. In case that this attribute is set to then DFL is Windows 2000 Mixed mode.

For msDS-Behavior-Version attribute value and its corresponding DFL check below list

  • 0 – Windows 2000 Native mode
  • 1 – Windows Server 2003 Interim mode
  • 2 – Windows Server 2003 mode
  • 3 – Windows Server 2008 mode
  • 4 – Windows Server 2008 R2 mode
  • 5 – Windows Server 2012 mode
  • 6 – Windows Server 2012 R2 mode

To get Forest Functional Level mode, you need to check the same msDS-Behavior-Version attribute but in different AD object. This object is

cn=partitions,cn=configuration,dc=testenv,dc=local

on Configuration partition

Note! Remember that Forest Functional Level mode cannot be higher than Domain Functional Level. Its value may be equal or less but never HIGHER!

For msDS-Behavior-Version attribute value and its corresponding FFL check below list

  • 0 – Windows 2000 mode
  • 1 – Windows Server 2003 Interim mode
  • 2 – Windows Server 2003 mode
  • 3 – Windows Server 2008 mode
  • 4 – Windows Server 2008 R2 mode
  • 5 – Windows Server 2012 mode
  • 6 – Windows Server 2012 R2 mode

that’s all available option at this moment, so now it is possible to prepare PowerShell script checking that attribute and comparing it to above lists

Windows PowerShell module for Active Directory

Open Windows PowerShell or Windows PowerShell module for AD and use below syntax to get Domain Functional Level mode (in case that you are using module for AD, you don’t need to use Import-Module cmd-let!)

Import-Module ActiveDirectory
Get-ADObject -Identity "dc=testenv,dc=local" -Properties * | Select msDS-Behavior-Version,ntMixedDomain

Windows PowerShell syntax for DFL

Get-ADObject -Identity "cn=partitions,cn=configuration,dc=testenv,dc=local" -Properties * | Select msDS-Behavior-Version

Windows PowerShell syntax for FFL

Remember to change domain distinguished name from dc=testenv,dc=local to yours

Now, it’s time to see complete script which displays more friendly output for user

Import-Module ActiveDirectory
Clear-Host
Write-Host ""
Write-Host "Domain Functional Level is " -ForegroundColor Green -NoNewLine
$domain=Get-ADObject -Identity "dc=testenv,dc=local" -Properties * | Select msDS-Behavior-Version,ntMixedDomain
if ($domain.ntMixedDomain -eq 1){
Write-Host "Windows 2000 Mixed mode" -ForegroundColor Yellow
}
else {
switch ($domain."msDS-Behavior-Version")
{
0 { Write-Host "Windows 2000 Native mode" -ForegroundColor Yellow }
1 { Write-Host "Windows Server 2003 Interim mode" -ForegroundColor Yellow }
2 { Write-Host "Windows Server 2003 mode" -ForegroundColor Yellow }
3 { Write-Host "Windows Server 2008 mode" -ForegroundColor Yellow }
4 { Write-Host "Windows Server 2008 R2 mode" -ForegroundColor Yellow }
5 { Write-Host "Windows Server 2012 mode" -ForegroundColor Yellow }
6 { Write-Host "Windows Server 2012 R2 mode" -ForegroundColor Yellow }
default { Write-Host "unknown" -ForegroundColor Red }
}
}
Write-Host ""
Write-Host "Forest Functional Level is " -ForegroundColor Green -NoNewLine
$forest=Get-ADObject -Identity "cn=partitions,cn=configuration,dc=testenv,dc=local" -Properties * | Select msDS-Behavior-Version
switch ($forest."msDS-Behavior-Version")
{
0 { Write-Host "Windows 2000 mode" -ForegroundColor Yellow }
1 { Write-Host "Windows Server 2003 Interim mode" -ForegroundColor Yellow }
2 { Write-Host "Windows Server 2003 mode" -ForegroundColor Yellow }
3 { Write-Host "Windows Server 2008 mode" -ForegroundColor Yellow }
4 { Write-Host "Windows Server 2008 R2 mode" -ForegroundColor Yellow }
5 { Write-Host "Windows Server 2012 mode" -ForegroundColor Yellow }
6 { Write-Host "Windows Server 2012 R2 mode" -ForegroundColor Yellow }
default { Write-Host "unknown" -ForegroundColor Red }
}
Write-Host ""

Copy above code and put it into notepad, save it as ps1 file and execute in Windows PowerShell environment

Script output

Quest PowerShell module for Active Directory

To be able to run below code, you need to have installed free Quest PowerShell module for Active Directory

If you have this available then you can run below syntax

Get-QADObject -Identity "dc=testenv,dc=local" -IncludeAllProperties | Select msDS-Behavior-Version,ntMixedDomain

Quest PowerShell syntax for DFL

Get-QADObject -Identity "cn=partitions,cn=configuration,dc=testenv,dc=local" -IncludeAllProperties | Select msDS-Behavior-Version

Quest PowerShell syntax for FFL

Remember to change domain distinguished name from dc=testenv,dc=local to yours

Now, it’s time to see complete script which displays more friendly output for user

Clear-Host
Write-Host ""
Write-Host "Domain Functional Level is " -ForegroundColor Green -NoNewLine
$domain=Get-QADObject -Identity "dc=testenv,dc=local" -IncludeAllProperties | Select msDS-Behavior-Version,ntMixedDomain
if ($domain.ntMixedDomain -eq 1){
Write-Host "Windows 2000 Mixed mode" -ForegroundColor Yellow
}
else {
switch ($domain."msDS-Behavior-Version")
{
0 { Write-Host "Windows 2000 Native mode" -ForegroundColor Yellow }
1 { Write-Host "Windows Server 2003 Interim mode" -ForegroundColor Yellow }
2 { Write-Host "Windows Server 2003 mode" -ForegroundColor Yellow }
3 { Write-Host "Windows Server 2008 mode" -ForegroundColor Yellow }
4 { Write-Host "Windows Server 2008 R2 mode" -ForegroundColor Yellow }
5 { Write-Host "Windows Server 2012 mode" -ForegroundColor Yellow }
6 { Write-Host "Windows Server 2012 R2 mode" -ForegroundColor Yellow }
default { Write-Host "unknown" -ForegroundColor Red }
}
}
Write-Host ""
Write-Host "Forest Functional Level is " -ForegroundColor Green -NoNewLine
$forest=Get-QADObject -Identity "cn=partitions,cn=configuration,dc=testenv,dc=local" -IncludeAllProperties | Select msDS-Behavior-Version
switch ($forest."msDS-Behavior-Version")
{
0 { Write-Host "Windows 2000 mode" -ForegroundColor Yellow }
1 { Write-Host "Windows Server 2003 Interim mode" -ForegroundColor Yellow }
2 { Write-Host "Windows Server 2003 mode" -ForegroundColor Yellow }
3 { Write-Host "Windows Server 2008 mode" -ForegroundColor Yellow }
4 { Write-Host "Windows Server 2008 R2 mode" -ForegroundColor Yellow }
5 { Write-Host "Windows Server 2012 mode" -ForegroundColor Yellow }
6 { Write-Host "Windows Server 2012 R2 mode" -ForegroundColor Yellow }
default { Write-Host "unknown" -ForegroundColor Red }
}
Write-Host ""

Script output

Now, we have two scripts, one to check schema version and one to check DFL and FFL. If you wish, you may combine them into one and get all necessary information in one output 🙂

<<< Previous part

Author: Krzysztof Pytko

5 { Write-Host "Windows Server 2012 mode" -ForegroundColor Yellow }

Schema version using PowerShell

 

I’ve just played with PowerShell in my test environment and I was wondering if it’s possible to verify Active Directory Schema version in some simple way using it. As I know that schema version number is stored in objectVersion attribute of

"cn=Schema,cn=Configuration,dc=domain,dc=local" object

I found that there is in PowerShell cmd-let which allows to query that object and get its attributes

So,you need to simply type below syntax of cmd-let to get version of schema in a domain

for Windows PowerShell (available when you have at least one Domain Controller based on Windows Server 2008R2)

Get-ADObject -Identity "cn=Schema,cn=Configuration,dc=testenv,dc=local" -Properties * | Select objectVersion

Schema version using Windows PowerShell

for Quest PowerShell (required download from 3rd party website. This is free tool)

Get-QADObject -Identity "cn=Schema,cn=Configuration,dc=testenv,dc=local" -IncludeAllProperties | Select objectVersion

Schema version using Quest PowerShell

as you can see, this was very short and quick way to get information about schema version 🙂 However, I went one step further and I prepared some script which checks objectVersion and writes on the screen its OS name. Basically, I started with if syntax but it was not the best possible solution for that. I started looking in the Internet if there is something like “case” which I remember from Turbo Pascal 😀 … and I found … this is switch in PowerShell. So, after I used switch, my code looks better and I’ve decided to share it here 🙂 (perhaps someone would find it useful)

Below you can find complete script code for Windows and Quest PowerShell

Windows PowerShell module for Active Directory

Import-Module ActiveDirectory

Clear-Host
Write-Host ""

Write-Host "Schema version is " -ForegroundColor Green -NoNewLine

$schema_ver=Get-ADObject -Identity "cn=Schema,cn=Configuration,dc=testenv,dc=local" -Properties * | Select objectVersion

switch ($schema_ver.objectVersion)
 {

 13 { Write-Host "Windows 2000 Server" -ForegroundColor Yellow }
 30 { Write-Host "Windows Server 2003" -ForegroundColor Yellow }
 31 { Write-Host "Windows Server 2003 R2" -ForegroundColor Yellow }
 44 { Write-Host "Windows Server 2008" -ForegroundColor Yellow }
 47 { Write-Host "Windows Server 2008 R2" -ForegroundColor Yellow }
 51 { Write-Host "Windows Server 8 Developers Preview" -ForegroundColor Yellow }
 52 { Write-Host "Windows Server 8 Beta" -ForegroundColor Yellow }
 56 { Write-Host "Windows Server 2012" -ForegroundColor Yellow }
 69 { Write-Host "Windows Server 2012 R2" -ForegroundColor Yellow }
 72 { Write-Host "Windows Server Technical Preview (2014)" -ForegroundColor Yellow }
 81 { Write-Host "Windows Server Technical Preview 2 (2015)" -ForegroundColor Yellow }
 82 { Write-Host "Windows Server 2016 Technical Preview 3 (2015)" -ForegroundColor Yellow }
 85 { Write-Host "Windows Server 2016 Technical Preview 4 (2015)" -ForegroundColor Yellow }
 87 { Write-Host "Windows Server 2016" -ForegroundColor Yellow }
default { Write-Host "unknown - "$schema_ver.objectVersion -ForegroundColor Red }  }  Write-Host ""

Copy above code and paste it to notepad, save as ps1  file and you will be able to execute it in your environment (remember that you need to change distinguished name of a domain from dc=testenv,dc=local to yours)

Script based on Windows PowerShell

Quest PowerShell module for Active Directory

Clear-Host
Write-Host ""

Write-Host "Schema version is " -ForegroundColor Green -NoNewLine

$schema_ver=Get-QADObject -Identity "cn=Schema,cn=Configuration,dc=testenv,dc=local" -IncludeAllProperties | Select objectVersion

switch ($schema_ver.objectVersion)
{

13 { Write-Host "Windows 2000 Server" -ForegroundColor Yellow }
30 { Write-Host "Windows Server 2003" -ForegroundColor Yellow }
31 { Write-Host "Windows Server 2003 R2" -ForegroundColor Yellow }
44 { Write-Host "Windows Server 2008" -ForegroundColor Yellow }
47 { Write-Host "Windows Server 2008 R2" -ForegroundColor Yellow }
51 { Write-Host "Windows Server 8 Developers Preview" -ForegroundColor Yellow }
52 { Write-Host "Windows Server 8 Beta" -ForegroundColor Yellow }
56 { Write-Host "Windows Server 2012" -ForegroundColor Yellow }
69 { Write-Host "Windows Server 2012 R2" -ForegroundColor Yellow }
72 { Write-Host "Windows Server Technical Preview (2014)" -ForegroundColor Yellow }
81 { Write-Host "Windows Server Technical Preview 2 (2015)" -ForegroundColor Yellow }
82 { Write-Host "Windows Server 2016 Technical Preview 3 (2015)" -ForegroundColor Yellow }
85 { Write-Host "Windows Server 2016 Technical Preview 4 (2015)" -ForegroundColor Yellow }
87 { Write-Host "Windows Server 2016" -ForegroundColor Yellow }
default { Write-Host "unknown - "$schema_ver.objectVersion -ForegroundColor Red }  }  Write-Host ""

Copy above code and paste it to notepad, save as ps1  file and you will be able to execute it in your Quest PowerShell environment (remember that you need to change distinguished name of a domain from dc=testenv,dc=local to yours)

Script for Quest PowerShell

I hope it would be useful for you.

Next part >>>

Author: Krzysztof Pytko