Chapter 6: Configuring and Implementing Local Policies – Microsoft Exam MD-100 Windows 10 Certification Guide

Chapter 6: Configuring and Implementing Local Policies

All settings in Windows 10 are stored in the registry. The registry is a database that contains details of all your settings, applications, device drivers, and many more. Without the registry, Windows will not work.

This chapter will introduce how to configure devices by using local policies, configure the local registry, and troubleshoot group policies in Windows 10. Group policy is a centrally managed technology that is designed to manage and control Windows 10 devices. The local group policy is the local implementation of these policies, and you need to know how you can configure local settings on a computer using these policies.

The following topics will be covered in this chapter:

  • Configuring the local registry
  • Configuring local policies
  • Implementing account policies
  • Troubleshooting group policies

This chapter will provide you with the skills to configure local policies and understand the registry in Windows 10 so that you can configure policies and the registry. This chapter will also help you to prepare for the MD-100 (Windows 10) exam, which is part of the Microsoft 365 Certified: Modern Desktop Administrator Associate certification.

Technical requirements

This chapter will use PowerShell code. This code is available on the GitHub page at

In this chapter, you will implement and configure local policies and registry keys. The steps that you will follow are also recorded. You can find these videos here:

Configuring the local registry

The Windows registry is the heart of the Windows 10 Operating System (OS). All of the settings are stored in the registry. The registry is a database that contains all of the Windows settings, installed software, device drivers, and many more settings. Without this registry, Windows 10 would not work.

You should take care when working with or editing the registry. An incorrect change in the registry can result in an unreliable OS, with a reinstallation of the OS as a solution. You should always create a backup of the registry before editing the registry.

To better handle the registry, we must understand the registry structure first.

Understanding the registry structure

The registry is organized hierarchically. At the top level, there are five registry hives. These five hives are DEFAULT, SAM, SECURITY, SOFTWARE, and SYSTEM. These five hives are a distinct collection of related settings that are structured as a series of keys, subkeys, and values. You can find the registry in C:\Windows\System32\Config. Inside this system folder, you will find several binary files that the registry uses.

The following screenshot will show you the binary files, as mentioned earlier, in the corresponding C:\Windows\System32\config folder:

Figure 6.1 - The binary files from the registry

The preceding screenshot shows the binary files and the hives they relate to in the registry, given as follows:

  • The SAM binary file belongs to the HKEY_LOCAL_MACHINE\SAM hive.
  • The SECURITY binary file belongs to the HKEY_LOCAL_MACINE\SECURITY hive.
  • The SOFTWARE binary file belongs to the HKEY_LOCAL_MACINE\SOFTWARE hive.
  • The SYSTEM binary file belongs to the HKEY_LOCAL_MACINE\SYSTEM hive.
  • The DEFAULT binary file belongs to the HKEY_USERS\.DEFAULT hive.

    Important Note

    The SAM file is used to store the users' passwords. There is also the USERDIFF binary file. This file is used only for Windows upgrades and will not be visible on some Windows 10 installations.

The vast majority of changes to the registry are made automatically by Windows whenever you install an application or change a setting inside an application, by using the Settings app or the Control Panel.

Now that we have understood the registry structure, let's move on to understanding the Registry Editor.

Understanding the Registry Editor

With the built-in Registry Editor, you can view, search, and modify the registry. Some common tasks that you can perform using the Registry Editor are as follows:

  • Search the registry for keys and values.
  • Create, delete, and modify keys and values.
  • Import registry entries from the .REG files.
  • Export registry entries into the .REG files.
  • Back up the registry.

To open the Registry Editor, follow the next steps:

  1. Click on the Start button.
  2. Type registry.
  3. Click on Registry Editor, as seen in the following screenshot:

Figure 6.2 - The Registry Editor

We are now going to learn about the previously mentioned five registry hives.

Registry hives

When the Registry Editor is open, you will see five top-level hives. The five top-level hives are given as follows:

  • HKEY_CLASSES_ROOT: This registry hive contains file association information and defines which application opens when the user double-clicks a file type on the file system.
  • HKEY_CURRENT_USER: This registry hive contains configuration information for the currently signed-in user. Items such as the users' Windows color scheme and font settings are stored in relevant values in this hive.
  • HKEY_LOCAL_MACHINE: This registry hive is probably the most important and the one that you likely will make the most edits to. It stores all computer-related configuration settings.
  • HKEY_USERS: This registry hive contains a collection of all of the configuration information for all users that have signed in locally to the computer, including the currently signed-in user.
  • HKEY_CURRENT_CONFIG: This registry hive contains information about the current hardware profile that the local computer used during system startup.

Most likely, you will make direct changes only to the values that stored are in the HKEY_LOCAL_MACHINE and HKEY_CURRENT_USER hives.

Registry keys and subkeys

To maintain structure within the database, similar settings are stored in folders and subfolders known as keys and subkeys. This makes it easier to reference a registry value. An example of a key is as follows:

HKEY_CURRENT_USER\Control Panel\Desktop

Let's now understand registry values.

Registry values

Values define the behavior of the OS, and they are stored in keys and subkeys. There are many types of values, depending on the type of data that each store.

In the previous registry path, you can find a value called Wallpaper. This value stores the name and location of a user's desktop wallpaper. In the following screenshot, you will see the key, value, and path to the Wallpaper:

Figure 6.3 - The value of a registry key

In a registry value, you can store text values, numerical data, variables, and similar data. The following table lists the more common types of registry values:

Table 6.1 - Common types of registry values

At this stage, you know what the registry is, how it is built, how it works, and how you can change keys. In the next section, we will look at configuring local policies and especially various security policies.

Configuring local policies

A group policy controls the environment of user accounts and computer accounts. A set of group policies is called a Group Policy Object (GPO). And one set of a group policy is called a Local Group Policy (LGPO). The difference between group policy objects and the local group policy is that GPOs are managed centrally and distributed across the Active Directory members, and an LGPO is managed decentrally and is intended for members without Active Directory, for example, standalone computers.

GPOs are processed in the following order:

  • Local
  • Site
  • Domain
  • Organizational Unit

Local policies are becoming effective when a user is logging in to a Windows 10 device. In this local policy, you can configure user settings and/or computer settings. For example, you can configure policies that implement auditing, specify user rights, and set security options. These three settings will be handled in the next sections.

Configuring the Audit Policy

The audit policy is used to provide information about basic audit policies of user actions on a Windows 10 device. These actions are recorded as a successor as a failure event. Auditing allows you to create a history of tasks and actions, such as file access and successful login attempts. Auditing can be also used for security violations. To configure the audit policy, three components are involved. These components are as follows:

  • Enable auditing for success or failure (or both) for specific actions and events.
  • Enable auditing for object access, such as file system files and folders.
  • To view the results of auditing in the security log, you can use the Event Viewer.

To configure an audit policy to monitor, in this example, account logon events, follow these steps:

  1. Click Start and type Secpol.msc.
  2. Click on Local Security Policy.
  3. In the Local Security Policy window, click on the Local Policies | Audit Policy tab.
  4. Double-click on Audit account logon events.
  5. In the Audit account logon events Properties window, check the Success and Failure boxes:

    Figure 6.4 - The Audit account logon event Properties window

  6. Then, click OK.
  7. Log off from the device and log back in with an Administrator account, but with the wrong password, so you will generate a failure event.
  8. Log in again, but now with the correct password.
  9. Click Start and search for the Event Viewer.
  10. Click on Event Viewer.
  11. In the Event Viewer, expand Windows Logs and select the Security log.
  12. You should see an event with an Event ID of 4776.
  13. Open this event and note the error message, as shown in the next screenshot:

Figure 6.5 - The event log of the logon failure

Now you know how to configure audit account logon events, we can proceed to specify and grant a user the right to perform a volume maintenance task.

Specifying user rights

User rights are used to determine which rights are applied to a user or to a group of users and are applied to the local Windows 10 device. These rights allow users to perform tasks on a Windows 10 device and can override permissions that have been set on specific objects. Some of the activities that you can specify for a user are as follows:

  • Adding workstations to domain
  • Allowing logon locally
  • Allowing logon through Remote Desktop Services
  • Backing up files and directories
  • Changing the time zone
  • Performing volume maintenance tasks
  • Taking ownership of files or other objects

In the next steps, we will configure the Perform volume maintenance tasks set for a user:

  1. Click Start and type Secpol.msc.
  2. Click on Local Security Policy.
  3. In the Local Security Policy window, click on the Local Policies | User Rights Assignment tab.
  4. Double-click on the Perform volume maintenance tasks user right:

    Figure 6.6 - The Perform volume maintenance tasks Properties window

  5. Click on Add User or Group, and the Select Users or Groups dialog box opens.
  6. Search for the user you want to give this right to and click twice on OK.
  7. Now you have selected another user to perform this task, as shown in the next screenshot:

Figure 6.7 - The user is added to perform a task

In the previous steps, you have specified a user right to a user or group. In the next section, we will look at the Security Options that you can configure.

Configuring Security Options

There are many options to configure in the Security Options section of the Local Security Policy. These options are used to allow or deny activities on a Windows 10 device.

The Accounts: Block Microsoft accounts, Devices: Restrict CD-ROM access to locally logged-on user only, User Account Control: Behavior of the elevation prompt for standard users, and Shutdown: Clear virtual memory pagefile settings are a few options that you can configure to allow or deny activities. They describe the best practices for the respective security policy setting.

The following screenshot shows you the Security Options settings window:

Figure 6.8 - The Security Options policy window

From the previous screenshot, almost all of the Security Options settings have their default setting set to Not Defined. Once configured, a setting can have the following statuses:

  • Enabled or Disabled
  • Text entry
  • Value

My advice is to go through the list of the Security Options, so you are aware of what you can configure.

Now, you know how you can configure and understand some local policies; up next, you will learn how to implement the local policies, and you will create some local account policies such as account lockout and password complexity.

Implementing account policies

In the previous section, you learned how you could open the Local Security Editor to configure Local Policies to the user or computer. In the Local Security Editor, you can also configure Account Policies within this Local Security Editor.

Important Note

These policies only work for local accounts and not for Microsoft accounts.

With the Account Policies, you can configure policies such as password policies and account lockout policies.

Configuring a Password Policy

If you want to ensure that all users on a local device use secure passwords and these are changed after several days, you can configure a Password Policy. Follow the next steps to configure a Password Policy:

  1. Click Start and type Secpol.msc.
  2. Click on Local Security Policy.
  3. In the Local Security Policy window, click on the Account Policies | Password Policy tab:

    Figure 6.9 - The password policies settings

  4. We first double-click on Enforce password history.
  5. Change the value to a number that represents the number of unique passwords (that must be used before the user can reuse an old password) and click OK:

    Figure 6.10 - The Enforce password history Properties window

  6. Then, we go back to the Local Security Policy window and click on the Account Policies | Password Policy tab.
  7. Double-click on Maximum password age.
  8. The default setting is 42 days. This means that users are required to change their password after 42 days. The best practice for this setting is to set the days between 30 and 90 days. After you changed this setting, click OK:

    Figure 6.11 - The Maximum password age Properties window

  9. We again go back to the Local Security Policy window and then click on the Account Policies | Password Policy tab.
  10. Double-click on Minimum password age.
  11. The default setting is 0 days. This means that users can change their passwords whenever they want. My advice here is to change this setting to, for example, 7 days. After you change this setting, click OK:

    Figure 6.12 - The Minimum password age Properties window

  12. We again go back to the Local Security Policy window and click on the Account Policies | Password Policy tab.
  13. Double-click on Minimum password length.
  14. The default setting is 0 characters. To use a more secure password length, change this setting to 8 characters and click OK:

    Figure 6.13 - The Minimum password length Properties window

  15. Going back again to the Local Security Policy window, click on the Account Policies | Password Policy tab.
  16. Double-click on Password must meet complexity requirements.
  17. Change this setting to Enabled to meet the complexity requirements and click OK:

    Figure 6.14 - The Password must meet complexity requirements Properties window

  18. We again go back to the Local Security Policy window and click on the Account Policies | Password Policy tab.
  19. The last setting you can configure is the Store passwords using reversible encryption setting. By default, this setting is Disabled. If you Enabled this setting, all of the passwords are stored in plaintext, so applications can access these passwords. But this makes them vulnerable to hackers who might access these passwords:

Figure 6.15 - The Store passwords using reversible encryption Properties window

If you followed the previously mentioned steps to configure the Password Policy, then your policy editor window must look like the following screenshot:

Figure 6.16 - The configured settings of the Password Policy

These settings are applied immediately, but if there are already users logged on, then they can work further with their existing passwords. The next time a user needs to change their password, the new password must comply with the settings you have configured in the Password Policy.

If the Password must meet complexity requirements policy is Enabled, passwords must meet the following minimum requirements:

  • They should not contain the user's account name or parts of the user's full name that exceed two consecutive characters.
  • They should be at least six characters in length.
  • They should contain characters from at least three of the following four categories: English uppercase characters (A through Z), English lowercase characters (a through z), base 10 digits (0 through 9), and non-alphabetic characters (for example, !, $, #, %).
  • Complexity requirements are enforced when passwords are changed or created.

In the previous steps, you have successfully configured a Password Policy. In the next section, you will learn to configure the Account Lockout Policy.

Configuring the Account Lockout Policy

When you implement a secure Password Policy, it is recommended to configure an Account Lockout Policy as well. An Account Lockout Policy is used by administrators to lock an account after several failed login attempts. This prevents malicious users from breaking into your computer systems. You can configure Windows devices to respond to this type of potential attack by disabling the account for some time.

Follow the next steps to configure an Account Lockout Policy:

  1. Click Start and type Secpol.msc.
  2. Click on Local Security Policy.
  3. In the Local Security Policy windows, click on the Account Policies | Account Lockout Policy tab.
  4. Double-click on Account lockout threshold.
  5. Fill in a value, for example, 4, and press OK:

    Figure 6.17 - The Account lockout threshold

  6. When the previous steps are completed, Windows 10 will suggest the two other settings: Account Lockout Duration and Reset account lockout counter after.

    Account Lockout Duration determines the number of minutes that a locked-out account remains locked out for before automatically becoming unlocked.

    Reset account lockout counter after determines the number of minutes that must elapse after a failed login attempt occurs before the failed login attempt counter is reset to 0 bad login attempts.

    The following screenshot shows you the Suggested Value Changes window:

    Figure 6.18 - Suggested Value Changes window

  7. Click OK to close the Suggested Value Changes window.
  8. Now the other two settings have the suggested values, the Account Lockout Policy will look something like the next screenshot:

Figure 6.19 - The Account Lockout Policy with the configured settings

In this section, you learned how to configure a Password Policy and an Account Lockout Policy. In the next section, we will learn how we can troubleshoot group policies.

Troubleshooting group policies

You should now be able to understand how to perform basic troubleshooting of Group group policies in Windows 10. We are not going to deep dive into every Group Policy because that is too much to cover in this book.

In general, when we refer to Group Policy, we are referring to Group Policy Objects (GPO) that contain Group Policy settings that are created by you as an IT administrator and are deployed to devices in a domain environment. Local Group Policy refers to policy settings that are locally administered and configured. A Group Policy can fail when applied to a Windows 10 device and there can be many reasons for this, such as incorrect GPO settings or a poor network connection.

Before you start investigating failed group policies, you can do a preliminary check in the following areas:

  • Group Policy Client Service: Check whether this service has the status Running or Automatic in the Services.msc utility.
  • Network Connection: Verify the network connection.
  • Time: The time difference between the client and the server needs to be within five minutes of the time on the server.

To investigate these issues, you can use different tools, such as the Resultant Set of Policy (RsoP.msc) tool and the Group Policy Result (GPResult) tool from the command line.

Resultant Set of Policy

The Resultant Set of Policy tool is a diagnostic tool that is built into Windows 10 and is used to check and troubleshoot group policy settings. With this tool, you can view which group policy is being applied to the computer and user, and you can identify which source the policy is coming from. Besides this, you can use the tool to simulate new or modified group policy objects for planning purposes.

There are two modes that the tool can be run in; these modes are as follows:

  • Logging Mode: It generates a report of policy settings for users and computers.
  • Planning Mode: It can be used for what-if scenarios.

For running the tool to determine the applied user and computer policy settings, follow the next steps:

  1. Click Start, then type and select rsop.msc.
  2. The Resultant Set of Policy window will open; it runs straight away and generates a report for the user and computer policy settings.
  3. In the Resultant Set of Policy window, you can view the applied settings for your user account and your computer account:

    Figure 6.20 - The RSoP output window

  4. To simulate group policy object settings, you can use the planning mode of the Resultant Set of Policy tool. You must open an empty Microsoft Management Console (MMC) and add the Resultant Set of Policy snap-in. In the MMC, select the Resultant Set of Policy and select the Generate Rsop Data from the Action menu. In the Resultant Set of Policy wizard, choose Planning mode and finish the wizard:

Figure 6.21 - The Resultant Set of Policy Planning mode option

After you have run the wizard, you can view the results. You can use this to review the policy settings if you want to implement new policies in your environment.

Important Note

Planning mode is only available when the computer is connected to an Active Directory environment.

Besides the Resultant Set of Policy tool, you also have the GPResult tool.

Learning about the GPResult tool

The GPResult command-line tool provides you with the relevant group policies that are applied to a user or a Windows 10 device. This tool creates a report that displays which GPOs are applied to a Windows 10 device and separates the user policies from the computer policies.

To see which GPOs are applied to your device, follow the next steps:

  1. Right-click Start and select Windows PowerShell (Admin).
  2. In the User Account Control dialog box, click Yes.
  3. Type the following command and press Enter:

    gpresult /r

  4. You should now see the RsoP data for your device, as shown in the following screenshot:

    Figure 6.22 - An example of the output from the gpresult command

  5. The output of the previous command will display the applied GPOs, the order of the GPOs, the details of the GPOs, the last applied time of the GPOs, the domain and functional level of the device, the domain controller is used to issue the GPO, the network speed threshold, the security groups of the user and computer are members of, and the details of the GPO filtering.

You can use command-line switches to fine-tune the report, for example, a user or a computer only. A few examples of command-line switches are as follows:

  • Display the applied GPOs to a specific user:

gpresult /r /scope:user

  • Display the applied GPOs to a specific computer:

gpresult /r /scope:computer

  • Generate an HTML report:

gpresult /h c:\gporeport.html

In this section, we learned how you can troubleshoot group policies. The most widely used tools for troubleshooting are the Resultant Set of Policies (RsoP) tool and the GPResult command-line tool. Group policies are reliable on our network infrastructure and the time difference between client and server.


In this chapter, you learned the basics of the registry. The registry contains registry hives, keys, and values. You also learned about the different value types.

You also learned about configuring local policies, such as configuring the audit policy, to monitor, for example, failed login attempts. You also learned how to configure specific user rights to give users, for example, the right to change the system time. With configuring security options, you learned to allow or deny users access to specific sources, such as a CD-ROM drive.

With the implementation of account policies, you have learned how to configure a Password Policy for secure passwords and to configure an Account Lockout Policy to prevent brute-force attacks on a Windows 10 device.

In the next chapter, we will look at how we can secure data and applications within Windows 10 to make use of the features that Windows 10 offers.


  1. Is the USERDIFF binary file by default present in Windows 10?
  2. Can you import or export registry keys?
  3. Is REG_DWORD_SZ a valid value type?
  4. Can you set the Maximum password age setting to 123 days?
  5. Can you use the RSoP Planning Mode on a standalone Windows 10 device?

Further reading