Archive | January 2015

Active Directory objects naming convention

 

Have you ever wondered about Active Directory objects naming convention in your domain environment? If not, but you wish to standardize their naming convention because your current one is not satisfactory then this article is for you.

Of course this is only a suggestion how to build the naming convention because there is no default and suitable template for all environments.

I will try to show you couple of examples for particular Active Directory objects and I hope you would be able to adjust them to your environment’s requirements.

Users

Every domain environment is full of users. That’s why good to have some naming convention for them to avoid mess.

The most popular template is based on user’s first and last name. This allows you to define variety naming conventions.

One of them defines user’s login combined with first name and last name separated by special character like:

  • dot
  • hyphen
  • underscore
  • no special character

Let’s take a look closer to an example for a person: Krzysztof Pytko. Possible logins could look like:

  • Krzysztof.Pytko
  • KrzysztofPytko
  • Krzysztof_Pytko
  • KrzysztofPytko

There is nothing wrong in this convention but what will happen if some day another Krzysztof Pytko would be hired in a company? In this case you need to somehow differentiate users. One of available options is to add a digit/number at the end of user’s login for example:

  • Krzysztof.Pytko1
  • Krzysztof.Pytko2

and so on.

Another option uses user’s last name and part of first name (let’s say 3 letters), in example:

  • pytkokrz

You can of course use a lot of variants based on a solution shown above but this also does not guarantee unique logins in the environment.

It’s good to have a naming convention which defines unique logins. One of option is to use employee number assigned by HR department. This should be unique for every employee in the company. Of course this might be difficult to remember by user but after few usages it should be easily remembered.

Let’s take a look for few examples

  • 1001000001
  • 0000001
  • 1150010001

everything depends on your company’s policy assigning employee numbers.

The last one example uses country and location identifiers with the next free number. Let’s consider this for Poland/Wroclaw for 15th employee

  • PLWRO015 (for smaller environments up to 1000 users in a location)
  • PLWRO0015 (for medium environments up to 10000 users in a location)
  • PLWRO00015 (for larger environments up to 100000 users in a location)
  • PLWRO000015 (for huge environments up to 1000000 users in a location)

That was not all possible options but this should show you a direction to create your own user’s naming convention.

Groups

As in previous paragraph, every domain is also full of groups. They are mostly used to grant access to resources but they have other purpose like:

  • role
  • fine-grained password policy
  • mail group
  • or other not mentioned here

However, regardless of their destination, every group must belongs to one of those types:

  • domain local
  • global
  • universal

So, you can use as group prefix, its type and it would look like:

  • l – for domain local groups
  • gfor global groups
  • ufor universal groups

OK, I have mentioned group prefix, so this probably means that I have some template to build group’s name? Yes, you’re right, I have something like that. Group naming convention relies on 2 variants in this case and depends on:

  • group is for resource access
  • group is not for resource access

 Let’s take a look what we need for group’s name, designated for resource access control:

  • group prefix
  • department owner
  • group role
  • group suffix

As group prefix, it’s good to choose group type, to simply underline what kind of type it is. Another possibility is to use prefix indicating for a group role. For department owner, specify short name or unique id of team to which it is designated. Group role should clearly define for what this group is used and it may be few words separated by hyphen () or underscore (_). However, I would recommend using hyphens only, it is much more readable form. Group suffix is mostly used only for resource access groups, which states if group has read-only (-r) or modify (-rw) permissions.

OK, let’s see few examples of resource groups for couple of departments:

  • IT department with licensing data
  • HR department with payroll data
  • Finance department with invoices
  • Common resources for all departments with instructions

All group types for IT department in above example are presented below:

  • litlicensing-datar (for read-only access); litlicensing-datarw (for modify access)
  • gitlicensing-datar (for read-only access); gitlicensing-datarw (for modify access)
  • uitlicensing-datar (for read-only access); uitlicensing-datarw (for modify access)

All group types for HR department with payroll data in above example are presented below:

  • lhrpayrollr; lhrpayrollrw
  • ghrpayrollr; ghrpayrollrw
  • uhrpayrollr; uhrpayrollrw

All group types for finance department with invoices data:

  • lfinanceinvoicer; lfinanceinvoicerw
  • gfinanceinvoicer; gfinanceinvoicerw
  • ufinanceinvoicer; ufinanceinvoicerw

and all group types for common resources share in read-only mode as modify is rarely used for all departments:

  • lallinstructionsr
  • gallinstructionsr
  • uallinstructionsr

That was not all possible options but this should show you a direction to create your own groups’s naming convention.

Computers and Servers

OK, now we are going into another important part on naming convention. This scheme is related with user devices and servers. It is really good to have common template for those machines as it would simply allow identifying them without logging on onto them.

There is a lot of possibilities and they rely on how much big is your environment. I will show you just couple of options which may direct you into your own scheme.

Computers

You need to remember that we are still limited to 15 characters in a computer name which is caused by NetBIOS.

Let’s start with the environments where up to 10000 computers in single location is enough.

CCLLLSVVFFFXXXX

where:

  • CC – is for country code
  • LLL – is a location code
  • S – is for operating system type (Windows, Unix, Linux, Solaris, BSD)
  • VV – is operating system version (XP, 07, 08, 81, 10)
  • FFF – is machine function (WKS, NTB, TAB, MOB)
  • XXXX – next number for machine

and below you can find few examples of scheme usage for 2 locations (Poland/Wroclaw and England/London):

  • PLWROW07WKS0001 (for computer with Windows 7)
  • PLWROW81WKS0005 (for computer with Windows 8.1)
  • PLWROW81NTB0015 (for notebook with Windows 8.1)
  • PLWROW81TAB0002 (for tablet with Windows 8.1)
  • UKLONWXPWKS0001 (for computer with Windows XP)
  • UKLONW07NTB0004 (for notebook with Windows 7)
  • UKLONW81TAB0150 (for tablet with Windows 8.1)

in a companies where more devices (up to 100000) are needed in one location, this convention might be selected (this is modification of this one above)

CCLLLSVVFFXXXXX

  • CC – is for country code
  • LLL – is a location code
  • S – is for operating system type (Windows, Unix, Linux, Solaris, BSD)
  • VV – is operating system version (XP, 07, 08, 81, 10)
  • FF – is machine function (PC, NB, TA, MO)
  • XXXXX – next number for machine

just short single example: PLWROW81PC00005

and a case for really large companies where up to 1000000 devices are needed in one location (this is modification of this one above)

  • CC – is for country code
  • LLL – is a location code
  • S – is for operating system type (Windows, Unix, Linux, Solaris, BSD)
  • VV – is operating system version (XP, 07, 08, 81, 10)
  • F – is machine function (Pc, Notebook, Tablet, Mobile)
  • XXXXXX – next number for machine

just short single example: UKLONW81T000015

Servers

Situation with servers name is similar to computers with the same limitation to 15 characters of NetBIOS name. You can simply apply the same scheme with small modifications.

Below scheme is good for environments where no more than 1000 servers of the same role are located within the same site.

CCLLLSVVRFFFXXX

where:

  • CC – is for country code
  • LLL – is a location code
  • S – is for operating system type (Windows, Unix, Linux, Solaris, BSD)
  • VV – is operating system version (03 – 2003, 08 – 2008, 12 – 2012)
  • R – is for operating system release (1 – release 1, 2 – release 2)
  • FFF – is machine function (DCR, DCW, FIL, PRT, APP, MGM)
  • XXX – next number for machine

Machine function in template above states:

  • DCR – Read-Only Domain Controller
  • DCW – Domain Controller
  • FIL – File Server
  • PRT – Print Server
  • APP – Application Server
  • MGM – Management Server

Ok, let’s consider few servers according to above naming convention:

  • PLWROW121DCW001
  • PLWROW122DCW002
  • PLWAWW122DCR001
  • PLWROW082FIL001
  • PLWROW082PRT001
  • PLPOZW032MGM003

this should be enough for most environments but if this is too less then you need to replace one server function character for the digit like:

CCLLLSVVRFFXXXX

you have less letters to describe more detailed server’s role but this allows you to have up to 10000 servers with the same role in the same site.

Let’s see short example of this scheme usage  PLWROW121APP0001

 Printers

To define printer naming convention you have a lot of possibilities, so I will present only one which seems to be good in my opinion. This is using:

SSSPMMMXXX

where:

  • SSS – printer signature
  • P – is it pooled or not (0 – no , 1 – pooled)
  • MMM – device manufacturer (SAM – Samsung, LEX – Lexmark, CAN – Cannon, HPP – HP Printer, KYO – Kyocera, RIC – Ricoh)
  • XXX – device number

Let’s see how this looks in practice:

  • PRT0LEX001
  • PRT0HPP002
  • PRT0RIC001
  • PRT1SAM001

Remember! Put detailed information of the printer’s location in printer’s properties as this is not available in naming convention.

I think that’s all for printers. As I said there is a lot of possibilities but I chose this one.

Group Policies

One more object remained on my list. This is GPO which is rarely used according to any naming convention. Especially in outsourced environments where many administrators are managing group policies.

I strongly suggest to apply some good scheme for those objects as it is much more convenient in management where a lot of policies are deployed.

For Group Policy naming convention you can use:

  • GPO prefix
  • GPO function (words separated by hyphen ““)
  • GPO suffix
  • GPO description (optional out of naming convention)

where GPO prefix is one of:

  • WIN – for Windows policies
  • CTX – for Citrix policies
  • RDS – for Terminal/Remote Desktop Services
  • TST – test policies
  • CUS – customer policies
  • OLD – old policies awaiting for removal

where GPO suffix is one of:

  • LPM – for loopback policy in merge mode
  • LPR – for loopback policy in replace mode
  • SCF – security filtering enabled
  • WMI – WMI filter applied
  • GPP – group policy preferences defined

basing on that, you can create GPOs in your environment. Below couple of examples:

  • winie-restrictions-control-panel
  • ctxscreen-saverlpr
  • tstwsus-updatescf
  • winfolder-mapping-drive-hgpp

and that’s all about naming convention in this article. I hope it was somehow helpful for you and you could build your custom naming convention for Active Directory objects.

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

Installing Windows Server 2012R2 – video

 

I have created a video blog on Youtube – iSiek’s video blog about Microsoft Windows services.

You will find there a video showing how to install Windows Server 2012R2 for Domain Controller role. Of course this may be applied to other Windows Server roles too and works the same way for installing Windows Server 2012.

and after server installation, please see another one for post-installation steps

I hope this method would be also useful for you. At this moment there is no voice in the video. I will try to change that in the nearest future 🙂

Author: Krzysztof Pytko

Windows Server 2003 end of lifetime coming soon

 

As you may heard, Microsoft Windows Server 2003 extended support is ending this year. Exact date is 14.07.2015 !!!

Windows Server 2003 end of support

Windows Server 2003 end of support

You may confirm this information at this site Microsoft Support Lifecycle

If you are surprised reading this note that means you should act quickly. After this date if you still want to have server system updates, you need to pay a lot of money to the company from Redmond.

I think it’s better to replace the old infrastructure with the new one. Especially Domain Controllers.

If you still are using Windows Server 2003 DCs you can start replacing them with newer operating system versions. Below you will find a list of articles which are helpful during this process.

Installing first Domain Controller with newer operating system

  1. Adding first Windows Server 2008 R2 Domain Controller within Windows 2003 network
  2. Adding first Windows Server 2012 Domain Controller within Windows 2003/2008/2008R2 network
  3. Adding first Windows Server 2012 R2 Domain Controller within Windows 2003/2008/2008R2/2012 network

Installing additional Domain Controllers

  1. Adding additional Windows Server 2008R2 Domain Controller
  2. Adding additional Domain Controller (Windows Server 2012)
  3. Adding additional Domain Controller (Windows Server 2012 R2)

Transferring FSMO roles to the new Domain Controller(s)

  1. Transferring FSMO roles from GUI
  2. Transferring FSMO roles from command-line
  3. Transferring FSMO roles with PowerShell

Advertising new time server

  1. Advertising new time server in domain environment

Decommissioning Windows Server 2003 Domain Controller(s)

  1. Decommissioning the old Domain Controller

Raising Domain and Forest functional levels

  1. Raising Domain Functional Level
  2. Raising Forest Functional Level

Setting domain password policy

  1. Domain Password Policy
  2. Setting default domain password policy
  3. Fine-Grained Password Policy in Windows Server 2008/2008R2
  4. Fine-Grained Password Policy in Windows Server 2012/2012R2

Enabling Active Directory Recycle Bin

  1. Active Directory Recycle Bin

Remote Domain Controller promotion

  1. Remote Domain Controller promotion

In case of issues you might find those articles useful:

  1. Decommissioning broken Domain Controller
  2. Seizing FSMO Roles
  3. Seizing FSMO roles with PowerShell
  4. Metadata cleanup for broken Domain Controller
  5. Metadata cleanup over GUI
  6. Re-registering time services
  7. Non-authoritative SYSVOL restore (FRS)
  8. Authoritative SYSVOL restore (FRS)
  9. Active Directory troubleshooting tools

I hope you would be able successfullt replace Windows Server 2003 Domain Controllers with newer operating systems.

Author: Krzysztof Pytko

Metadata cleanup over GUI

 

Sometimes we have problem with broken Domain Controller(s) within our environment. Then we do not think about consequences from removing failed DC from network. We just shut it down and replace with the new one, because mostly we have no system state backup of the old Domain Controller. Everything looks fine for us, we have no failed DC in a network. But Active Directory still knows about it and uses that DC for AD data replication which can cause errors.

To prevent replicating data between broken DC and the rest, you need to perform metadata cleanup.

This can be done using ntdsutil as I showed you some time ago in this article Metadata cleanup for broken Domain Controller or over graphical console – using Active Directory Users and Computers.

You still need to have Domain Admin account to do that and at least one Windows Server 2008 Domain Controller.

I will show you how to do that using Windows Server 2012 R2 Domain Controller but this is exactly the same procedure on previous servers.

To remove metadata about non-existing Domain Controller, log on to Windows Server 2008 or newer DC and open Active Directory Users and Computers console.

Click right mouse button (RMB) on start tile and choose “Run”

Execute run box

Execute run box

and type dsa.msc to open Active Directory Users and Computers console

Opening Active Directory Users and Computers console

Opening Active Directory Users and Computers console

Now, you need to go into main menu and search for “View -> Advanced features” option and select it

Selecting advanced features for ADUC console

Selecting advanced features for ADUC console

Now, go to “Domain Controllers” organizational unit and select Domain Controller for which you want to do metadata cleanup

Selection of Domain Controller to remove

Selection of Domain Controller to remove

Click on it RMB and choose “Properties

Properties of broken Domain Controller

Properties of broken Domain Controller

You need to check if this computer object is not protected by accidental deletion from domain environment. To see that, select “Object” tab. Looks if “Protect object from accidental deletion” is set. If so, uncheck it and apply changes.

Protect from accidental deletion check

Protect from accidental deletion check

Unchecking accidental deletion protection

Unchecking accidental deletion protection

Now, go back to Active Directory Users and Computers console to Domain Controllers OU and select this DC once again

Click RMB on it and choose “Deleteoption

Deleting broken Domain Controller from domain

Deleting broken Domain Controller from domain

Confirm that you are sure and you want to delete this object from the domain

Removing object from the domain

Removing object from the domain

You will get information that you are trying to remove Domain Controller from the domain without appropriate removal process

Domain Controller removal warning

Domain Controller removal warning

you are sure that this Domain Controller does not exists anymore and you wish to delete it anyway, so select this checkbox and confirm deletion

Confirm DC removal

Confirm DC removal

if your server was acting as Global Catalog, you need to confirm once again that you wish to delete it from the domain

Confirm DC removal

Confirm DC removal

There is one more place you need to visit to completely clean up your environment. Open Active Directory Sites and Services console and locate Site in which removed DC was authenticating objects

Sites and Services - removed DC

Sites and Services – removed DC

as you can see, this Domain Contoller has no NTDS Settiings object associated. Just click RMB on it and remove it

Removing DC from Sites and Services

Removing DC from Sites and Services

Confirm that you wnat to delete this object and that’s all!

Confirm DC object removal

Confirm DC object removal

You removed easily metedata of broken Domain Controller from your domain!

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

Setting default domain password policy

 

Every domain environment needs a default domain password policy.

You have it, am I right?

Even if you don’t know, default password policy is available in your domain. By default, you will find all its settings within “Default Domain Policy“. This policy is applied at domain level.

Default Domain Policy

Default Domain Policy

To start with domain password policy, please read the article I published some time ago: Domain Password Policy

The question is: did you review password policy settings and considered password requirements for your environment?

Or just like the most administrators: “Hey, I was hired to this company much more later when password policy was in-place. I did not need to touch it!

Oh really?! Do you know that you (as a domain administrator) are responsible for password security? Yes, you are! So, let’s take closer look at those settings and what you can configure as reasonable default password policy.

 Default password settings

When you deploy new domain, you don’t have to configure password policy from the scratch. There are default values set up.

Default password settings

Default password settings

Of course, password settings should be adjusted to your company needs. Leaving the defaults might not be appropriate and I would strongly recommend to do that.

Let’s see what we can configure there. You will find password policies in two nodes under

Computer Configuration -> Policies -> Windows Settings -> Security Settings -> Account Policies

These nodes are:

  • Password Policy
  • Account Lockout Policy

In Password Policy node you can configure:

  • Enforce password history
  • Maximum password age
  • Minimum password age
  • Minimum password length
  • Password must meet complexity requirements
  • Store passwords using reversible encryption

and in Account Lockout Policy node are these options:

  • Account lockout duration
  • Account lockout threshold
  • Reset account lockout counter after

Above options are responsible for building good password policy – default domain password policy.

Let’s see what they mean and what you can set up there.

Password Policy settings

This is really important node where you can define how the password would be built and how much secure it is. You need to remember that you are setting default password policy for your domain. All those settings will be applied to every domain account.

Password Policy settings

Password Policy settings

Remember! Users may complain about password setting but only then if you will force them to use very long passwords and if it will expire to often.

Enforce password history

To start building password policy you need to consider how many unique passwords user must set, before it would be possible to go back and use the oldest one.

For that “Enforce password history” setting is responsible. You need to define value, how many unique passwords are required to be set by user, before allowing him to use previous passwords.

Enforce password history explanation

Enforce password history explanation

Allowed value is between 0 (no password history) and 24 (maximum)

For default domain password policy I would suggest to set value of 10.

Changed enforce password history setting

Changed enforce password history setting

This is quite secure and allow much more simple calculation for other setting showed a little bit later in this article.

In this case, the setting means that user must set 10 unique passwords before he can go back and use first from the previous list of passwords.

There is slight chance that user would not reuse his passwords 🙂

Maximum password age

Another important setting in the policy is how often users must change their password.

Maximum password age explanation

Maximum password age explanation

Maximum password age value must be between 0 and 998 days.

Setting value of 0 causes that password expires every 0 days! That means in reality – password never expires

You definitively should avoid of using this value in productive environments! Especially that this is not easy to find out, because password never expires flag is not modified and you cannot see this directly in Active Directory Users and Computers console. Password never expires checkbox is NOT selected then!

Note! Good practice shows that password should be changed in range of 30 – 90 days.

When you set this value up too short, users would complain that they have to change password too often. This might cause a problem with “yellow sticks” around computer where users write their passwords!

For default domain password policy 90 days look reasonable and users are not complaining too much.

Maximum password age setting

Maximum password age setting

I would recommend of setting this value for the maximum password age. Password change once per 3 months is acceptable and no one should complain.

Minimum password age

This is really important setting and as I can see many administrators are afraid of setting this value to custom time.

Information! Minimum password age policy is responsible for controlling how often user is allowed to change the password.

Mostly, in the environments I see one of these two values:

  • 0 days
  • 1 day

By the default, you can find 1 day as minimum password age setting.

This means that user can change the password and in if he wants to do that again, he needs to wait 1 day before it would be possible again.

Minimum password age explanation

Minimum password age explanation

OK, but what’s wrong in this setting?

User is allowed to change the password once per day. That means, user can repeat this procedure every day to go back to his first (favourite) password.

At current stage, you defined 10 unique passwords, so after 10 days, user would be able to reuse his previous password again and use it for the next 80 days until system will force its change!

The situation looks even worse if the setting contains 0 days as a value.

There is no restriction to password change time limit for user! This means, user can simply go back to the previous password within the same day!

Setting strength options in other policies does not make sense as you can see, user would be able to have always the same password, all the time.

That’s why this setting is really important!

So, how should I set up this value?

I was wondering how to adjust this value in different environments and I figured it out.

I invented a formula to calculate appropriate value. Because password policies vary in every environment, I needed some common way to achieve this.

To simply calculate this value I used:

  • Enforce password history count
  • Maximum password age
Minumum password age formula

Minumum password age formula

This is really secure and reasonable value. You may be sure that user would not be able to reuse the first password during one password life cycle.

Hey, but users start complaining that they cannot change password on demand!

No, they would not! Believe me 🙂

The number of regular users, who are changing their passwords before forced by the system, is less than 1% in every environment.

Even administrator would not do that themselves 😀

Besides, they are allowed to change their password, but not every day.

That would help you to find out what is going on in your domain when some users will call IT department or HelpDesk too frequenty and request password change. Maybe an account is shared between other users? 🙂

Relying on this formula Minimum password age value is 10 days

Minimum password age

Minimum password age

and put calculated minimum password age into policy

Minimum password age setting

Minimum password age setting

Minimum password length

Ok, password life cycle is defined but we need to set up its length. You know that above settings would be nothing if you allow to use too simple password, rigth?

The setting should be chose wisely as enforcing users to set very long password might cause an issue with forgoten passwords or account lockouts. Sometimes it might be worse, they would use “yellow sticks” where password is written.

Possible values for this setting are between 1 and 14 characters.

Minimum password length explanation

Minimum password length explanation

When you set this up to 0 characters then password would not be required. Of course this is strongly not recommended!

Setting it between 8 -12 charactes is good enough and no one should complain.

Minimum password length setting

Minimum password length setting

Password must meet complexity requirements

Another important password policy setting.

If you do not use this option, your password policy would be weak.

Thanks to this setting you have to use 3 types of different characters out of 4 groups:

  • uppercase characters [A – Z]
  • lowercase characters [a – z ]
  • digits [0 – 9]
  • special characters [!@#$%^&*()-=_+]

This policy may be enabled or disabled. When it’s enabled, password is much more secure and of course I would recommend to have it enabled.

Password must meet complexity requirements explanation

Password must meet complexity requirements explanation

Store passwords using reversible encryption

That setting should never be enabled in default domain password policy unless you really need it and you have Windows Server 2000/2003 Domain Functional Level where Fine-Grained Password Policies are unavailable.

Enabling this setting causes that password is unsafe as it is stored like it would be saved in plain text!

Store passwords using reversible encryption explanation

Store passwords using reversible encryption explanation

That’s all about defined password policy strength.

Now it’s time to configure policies responisble for account lockout behavior.

Account Lockout Policy settings

Policies located under this node are responsible for locking account if user types password incorrectly few times in a row.

By default, they are unconfigured and account is not locking at all!

So, if this is not configured should I take care of it? If you are asking me – yes, always!

This should be configured in every domain environment. Even if you think that it is not necessary, turn it on.

Just set up Account lockout threshold value to something really high like 50. That’s quite enough failed logon attempts for users and still prevents infinite password guess by hackers or other dangerous stuff.

Let’s take a look at those policies and try to configure them reasonably.

Account lockout threshold

As mentioned above, if you think that you do not need this policy, turn it on and specify high number like 50 attempts

That’s quite enough failed logon attempts for users and still prevents infitite password guess by hackers or other dangerous stuff.

Account lockout threshold explanation

Account lockout threshold explanation

In other case when you would like to implement this feature in your environment, please follow below formula

Account lockout threshold formula

Account lockout threshold formula

This would allow your users to check every password used in the past and gives them extra 2 tries if some typo would appear in the password box. After that they will call IT or HelpDesk team 🙂

Based on that formula, current value is 12 failed logon attempts before account is locked out

Account lockout threshold value

Account lockout threshold value

Just set this up in the policy and 2 other option would activate

Account lockout threshold setting

Account lockout threshold setting

When you apply changes, another windows with 2 other settings appear filled with deafult values

Account lockout options

Account lockout options

Account lockout duration

Account lockout duration policy is responsible for locking a domain account for specified duration of time. When failed attempt logon count is reached, this policy locks temporarily the account.

When specified time passes, the account is unlocked and user may try to logon again using his credentials. To logon sooner, user needs to contact with IT or HelpDesk department and request manual account unlock.

Account lockout duration time explanation

Account lockout duration time explanation

Default value for this policy is reasonable. 30 minutes of account lockout is acceptable, after that time user is able to try to logon again.

If you need much more control when account is locked out, set up 0 as a value. Then account must be always unlocked by administrator.

Reset account lockout counter after

This setting must be less or equal to Account lockout duration time. It defines after what time failed logon attempt is reset and user may try to logon once again.

The setting gives user one more chance and if password is provided inproperly, account is locked out again for time specified in Accout lockout duration policy.

Reset account lockout counter after explanation

Reset account lockout counter after explanation

I would strongly recommend leaving the value with the same time as in Account lockout duration. Then users would not try to experiment with their password and do not extend lockout period.

When you implement all those setting in your password policy, take a look at its summary

New password policy summary

New password policy summary

it looks much better and much more secure than the deafult one and maybe better than your previous policy 🙂

Now, you need to only refresh password policy on your Domain Controllers and test if it is working fine for the next password change.

On Windows Server 2003, 2008 and 2008R2 open command line and type

gpudate /force
gpupdate /force

gpupdate /force

to start refreshing group policies

GPOs refreshed

GPOs refreshed

On Windows Server 2012 and 2012R2 use PowerShell cmd-let for that

Invoke-GPUpdate
Invoke-GPUpdate cmd-let

Invoke-GPUpdate cmd-let

to get the same result as above.

And that’s all. Your default domain password policy is wisely implemented.

If you wish to deploy other password policies for other group of users and you have at least Windows Server 2008 Domain Functional Level please read these articles on my blog how to do that.

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

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

Author: Krzysztof Pytko