Prepare Active Directory for site publishing

When you extend the Active Directory schema for System Center Configuration Manager, you introduce new structures to Active Directory that are used by Configuration Manager sites to publish key information in a secure location where clients can easily access it.

It's a good idea to use Configuration Manager with an extended Active Directory schema when you manage on-premises clients. An extended schema can simplify the process of deploying and setting up clients. An extended schema also lets clients efficiently locate resources like content servers and additional services that the different Configuration Manager site system roles provide.

• If you're not familiar with what extended schema provides for a Configuration Manager deployment, you can read about Schema extensions for System Center Configuration Manager to help you make this decision.
• When you don't use an extended schema, you can set up other methods like DNS and WINS to locate services and site system servers. These methods of service location require additional configurations and are not the preferred method for service location by clients. To learn more, read Understand how clients find site resources and services for System Center Configuration Manager,
• If your Active Directory schema was extended for Configuration Manager 2007 or System Center 2012 Configuration Manager, then you don't need to do more. The schema extensions are unchanged and will already be in place.

Extending the schema is a one-time action for any forest. To extend, and then use the extended Active Directory schema, follow these steps:

Step 1. Extend the schema

To extend the schema for Configuration Manager:

• Use an account that is a member of the Schema Admins security group.
• Be signed in to the schema master domain controller.
• Run the Extadsch.exe tool, or use the LDIFDE command-line utility with the ConfigMgr_ad_schema.ldf file. Both the tool and file are in the SMSSETUP\BIN\X64 folder on the Configuration Manager installation media.

Option A: Use Extadsch.exe

1. Run extadsch.exe to add the new classes and attributes to the Active Directory schema.
   Tip

   Run this tool from a command line to view feedback while it runs.
2. Verify that the schema extension was successful by reviewing extadsch.log in the root of the system drive.

Option B: Use the LDIF file

1. Edit the ConfigMgr_ad_schema.ldf file to define the Active Directory root domain that you want to extend:
   • Replace all instances of the text, DC=x, in the file with the full name of the domain to extend.
   • For example, if the full name of the domain to extend is named widgets.microsoft.com, change all instances of DC=x in the file to DC=widgets, DC=microsoft, DC=com.
2. Use the LDIFDE command-line utility to import the contents of the ConfigMgr_ad_schema.ldf file to Active Directory Domain Services:
   • For example, the following command line imports the schema extensions to Active Directory Domain Services, turns on verbose logging, and creates a log file during the import process: ldifde -i -f ConfigMgr_ad_schema.ldf -v -j .
3. To verify that the schema extension was successful, review a log file created by the command line used in the previous step.

Step 2. Create the System Management container and grant sites permissions to the container

After you extend the schema, you must create a container named System Management in Active Directory Domain Services (AD DS):

• You create this container one time in each domain that has a primary or secondary site that will publish data to Active Directory.
• For each container, you grant permissions to the computer account of each primary and secondary site server that will publish data to that domain. Each account needs Full Controlto the container with the advanced permission, Apply onto, equal to This object and all descendant objects.

To add the container

1. Use an account that has the Create All Child Objects permission on the System container in Active Directory Domain Services.
2. Run ADSI Edit (adsiedit.msc), and connect to the site server's domain.
3. Create the container:
   • Expand Domain , expand , right-click CN=System, choose New, and then choose Object.
   • In the Create Object dialog box, choose Container, and then choose Next.
   • In the Value box, enter System Management, and then choose Next.
4. Assign permissions:
   Note

   If you prefer, you can use other tools like the Active Directory Users and Computers administrative tool (dsa.msc) to add permissions to the container.
   • Right-click CN=System Management, and then choose Properties.
   • Choose the Security tab, choose Add, and then add the site server computer account with the Full Control permission.
   • Choose Advanced, choose the site server's computer account, and then choose Edit.
   • In the Apply onto list, choose This object and all descendant objects.
5. Choose OK to close the console and save the configuration.

Step 3. Set up sites to publish to Active Directory Domain Services

After the container is set up, permissions are granted, and you have installed a Configuration Manager primary site, you can set up that site to publish data to Active Directory.

Create a forest trust

To create a forest trust

1. Open Active Directory Domains and Trusts.
2. In the console tree, right-click the domain node for the forest root domain, and then click Properties.
3. On the Trust tab, click New Trust, and then click Next.
4. On the Trust Name page, type the DNS name (or NetBIOS name) of another forest, and then click Next.
5. On the Trust Type page, click Forest trust, and then click Next.
6. On the Direction of Trust page, do one of the following:
   • To create a two-way, forest trust, click Two-way.
     Users in this forest and users in the specified forest can access resources in either forest.
   • To create a one-way, incoming forest trust, click One-way:incoming.
     Users in the specified forest will not be able to access any resources in this forest.
   • To create a one-way, outgoing forest trust, click One-way:outgoing.
     Users in this forest will not be able to access any resources in the specified forest.
7. Continue to follow the wizard.

Important

• To successfully create a forest trust, your environment will need to be set up properly. For more information, see the checklist for creating a forest trust in Related Topics.

Notes

• To perform this procedure, you must be a member of the Domain Admins group (in the forest root domain) or the Enterprise Admins group in Active Directory, or you must have been delegated the appropriate authority. As a security best practice, consider using Run as to perform this procedure. For more information, see Default local groups, Default groups, and Using Run as.
• If you are a member of the Incoming Forest Trust Builders group, you can create one-way, incoming forest trusts to this forest.
• To open Active Directory Domains and Trusts, click Start, click Control Panel, double-click Administrative Tools, and then double-click Active Directory Domains and Trusts.
• On a domain controller running Windows Server 2003, the forest root domain is the first domain listed in the console tree in Active Directory Domains and Trusts. This configuration is not provided on domain controllers running Windows 2000.
• If you have the appropriate administrative credentials for each forest, you can create both sides of a forest trust at the same time by clicking Both this domain and the specified domain on the Sides of Trust page. For more information, see Related Topics.
• If you want users from the specified forest to have access to all computers in the local forest, on the Outgoing Trust Properties page, click Forest-wide authentication. This option is preferred when both forests belong to the same organization.
• If you want to selectively limit authentication to particular users and groups from the specified forest, on the Outgoing Trust Properties page, click Selective authentication. This option is preferred if the specified forest belongs to a separate organization.
• In addition to creating new trusts, you can modify existing trusts by clicking the Trust tab.
• The command-line tool Dsmod.exe does not support the addition of security principals in one forest to groups that are located in another forest when both forests are joined by a forest trust. You can use the Active Directory Users & Computers snap-in to add security principals across a forest trust.

How To Edit the Active Directory Using ADSI Edit

I think that it's probably safe to say that most Windows admins are familiar with the Active Directory. The Active Directory was first introduced with Windows 2000 Server, and will be turning 20 years old in a couple of years. Sure, the Active Directory has evolved a bit along the way, but it still adheres to the same basic structure that it did when it was first introduced so long ago.

Many of the Active Directory-related tools that we have today can also trace their roots back to much earlier versions of Windows. For example, the Active Directory Users and Computers tool that exists today in Windows Server 2016 really hasn't changed very much over the years.

The point is that Active Directory is a mature technology, and most Windows Server admins probably know how to use the various Active Directory tools to perform tasks such as creating user accounts, sites, and OUs. Even so, the usual Active Directory tools can be inadequate in some situations. These tools are designed to be safe, and to protect inexperienced administrators from making potentially catastrophic mistakes. Sometimes however, the same safety mechanisms that exist to protect us can also get in the way.  This is where the ADSI Edit tool comes into play.

Before I show you what the ADSI Edit tool looks like, and how to use it, I want to compare it to another tool that is built into Windows -- the Registry Editor. As I'm sure you know, the vast majority of Windows' configuration settings are stored in the Windows registry. In fact, many of the GUI based management utilities are really nothing more than registry front ends. When you use the Group Policy Editor to make a change to a policy for example, the Group Policy Editor is actually editing the registry behind the scenes on your behalf.

GUI-based tools such as the Group Policy Editor exist for two purposes. First, they make an administrator's life easier by exposing related settings in some sort of logical way. Imagine how much more difficult it would be to implement a complex collection of group policy settings if you had to track down each policy setting through Registry Editor.

The other thing that GUI based tools such as the Group Policy Editor do for us, is that they make basic administrative tasks much safer than they would be if we had to do everything through the Registry Editor. Editing the registry can be dangerous. If you make a mistake while editing the registry, you can destroy Windows. The various Windows administrative tools are designed to make registry edits much safer by acting as an isolation boundary between the administrator and potentially dangerous registry settings.

These are the same two things that the various Active Directory tools are designed to do. Such tools present the Active Directory elements in a more simplified and logical way, while also making the process of editing the Active Directory far less dangerous than it might otherwise be.

The problem with the built-in Windows administrative tools however, is that they can't help in every situation. Sometimes an administrator must directly edit the registry in order to fix a problem. That's where the Registry Editor comes into play. Similarly, there are some Active Directory problems that simply cannot be fixed using the usual tools, and that's where ADSI Edit comes into play. For example, I have used ADSI Edit to remove Active Directory remnants that were left behind by a failed Exchange Server installation. Like the Registry Editor however, ADSI Edit bypasses all of the usual safeguards, and you can do catastrophic damage by using it incorrectly, so it is a good idea to back up your Active Directory prior to using this tool.

The easiest way to access ADSI Edit is by choosing the ADSI Edit command from the Server Manager's Tools menu. Upon doing so, you will be presented with a condole screen that looks like the one shown in Figure 1.

Figure 1. This is what the ADSI Edit console looks like.

The first step in putting this tool to work is to connect it to your Active Directory. To do so, choose the Connect To command from the Action menu. This will bring up the Connection Settings dialog box. You must select the naming context that you want to connect to. In most cases the defaults work just fine, as shown in Figure 2.

Figure 2. In most cases you can get away with using the defaults.

Once you connect to the Active Directory, the console will look like what you see in Figure 3. Like the Registry Editor, ADSI Edit uses a hierarchical, tree view. The difference however, is that the option to expand the Default Naming Context and other layers of the hierarchy does not appear until the node is clicked on.

Figure 3. This is what it looks like after you connect to the Active Directory.

As you navigate the Active Directory, things should begin to look a lot more familiar. As you can see in Figure 4, ADSI Edit gives you the ability to move, delete, rename, or otherwise modify objects that you wouldn't ordinarily be able to.

Figure 4. This is what it looks like to use ADSI Edit.

PowerShell: Get-ADUser to see password last set and expiry information and more

Get-ADUser to see password last set and expiry information and more

Open Active Directory Module for Windows PowerShell To Run as administrator
help Get-ADUser









Get-ADUser -identity yaniv -properties *









get-aduser -filter * -properties passwordlastset, passwordneverexpires |ft Name, passwordlastset, Passwordneverexpires









get-aduser -filter * -properties passwordlastset, passwordneverexpires | sort name | ft Name, passwordlastset, Passwordneverexpires









Get-ADUser -filter * -properties passwordlastset, passwordneverexpires | sort-object name | select-object Name, passwordlastset, passwordneverexpires | Export-csv -path c:\yaniv.csv

What Is the System Reserved Partition and Can You Delete It?

Windows 7, 8, and 10 create a special “System Reserved” partition when you install them on a clean disk. Windows doesn’t normally assign a drive letter to these partitions, so you’ll only see them when you use Disk Management or similar utility.

The System Reserved partition was introduced with Windows 7, so you won’t find it on previous versions of Windows. The partition is also created on Windows Serer 2008 R2 and newer Server versions of Windows

What Does the System Reserved Partition Do?

The System Reserved partition contains two important things:

• The Boot Manager and Boot Configuration Data: When your computer starts, the Windows Boot Manager reads the boot data from the Boot Configuration Data (BCD) Store. Your computer starts the boot loader off of the System Reserved partition, which in turn starts Windows from your system drive. 
• The startup files used for BitLocker Drive Encryption: If you ever decide to encrypt your hard drive with BitLocker drive encryption, the System Reserved partition contains the necessary files for starting your computer. Your computer boots the unencrypted System Reserved partition, and then decrypts the main encrypted drive and starts the encrypted Windows system.

The System Reserved partition is essential if you want to use BitLocker drive encryption, which can’t function otherwise. Important boot files are also stored here by default, although you could store them on the main Windows partition if you preferred.

When Windows Creates the System Reserved Partition

The System Reserved partition consumes 100 MB of space on Windows 7, 350 MB of space on Windows 8, and 500 MB of space on Windows 10. The partition is typically created during the Windows installation process, just before the installer allocates space for the main system partition.

Can You Delete the System Reserved Partition?

You really shouldn’t mess with the System Reserved partition—it’s easiest and safest to just leave it be.

Windows hides the partition by default instead of creating a drive letter for it. Most people never notice they have a System Reserved partition unless they fire up disk tools for other reasons. The System Reserved partition is mandatory if you use BitLocker—or want to use it in the future.

Prevent the System Reserved Partition From Being Created

If you really don’t want this partition on your drive—for whatever reason—the ideal thing to do is prevent it from being created in the first place. Rather than create a new partition in unallocated space from within the Windows installer, you can create a new partition that consumes all unallocated space by using another disk-partitioning tool before running Windows installation.

When it comes time, point the Windows installer at the partition you created. The Windows installer accepts that there’s no room for System Reserved partition and installs Windows onto a single partition. Bear in mind that you’re still not saving the entire 100 MB, 350 MB, or 500 MB that the partition would have taken. The boot files instead must be installed on your main system partition.

To do this, you’ll need to use any disk-partitioning software except the graphical one in the Windows installer. However, you can actually do this from within the Windows installer. Just follow the following steps:

• Press Shift+F10 while installing Windows to open a Command Prompt window.
• Type diskpart into the Command Prompt window and press Enter.
• Create a new partition in the unallocated space using the diskpart tool. For example, if you have a single drive in the computer and it’s completely empty, you can just type select disk 0 and then create partition primary to select the first disk and create a new partition using the entire amount of unallocated space on the drive.
• Continue the setup process. Select the partition you created earlier when you’re asked to create a partition.

Remove an Existing System Reserved Partition

It may be possible to remove a System Reserved partition after installing Windows. You can’t just delete the System Reserved partition, though. Because the boot loader files are stored on it, Windows won’t boot properly if you delete this partition.

To delete the System Reserved partition, you first have to move the boot files from the System Reserved partition onto the main Windows system drive. And this is harder than it sounds. It involves messing with the Registry, copying various files between drives, updating the BCD store, and making the main system drive the active partition. On Windows 8, it also involves disabling and then re-enabling the Windows Recovery Environment. You’ll then have to remove the System Reserved partition and enlarge your existing partition to reclaim the space.

All this is possible, and you’ll find various guides on the web that walk you through the process. However, Microsoft does not officially support the technique and we don’t recommend it, either. You’ll gain a very tiny bit of space—less than the few hundred MB used by the System Reserved partition—at the cost of potentially messing up your operating system and losing the ability to use BitLocker drive encryption.

For reference, here’s why you shouldn’t just delete the System Reserved partition. We used the GParted partition editor on an Ubuntu live CD to delete the System Reserved partition, and then made the main Windows system partition bootable with no attempt at copying the boot files. We saw a message saying our Boot Configuration Data was missing, and that we’d have to repair our computer with Windows installation media.

This partition may look like it’s cluttering your drive and wasting space, but it performs important functions and removing it frees up almost no space. It’s best to simply ignore the partition, and if you really don’t want it to be there, prevent it from being created while installing Windows.

Upgrade Windows Server 2012R2 AD to Server 2016

I know that this is not really a good idea, but I had questions on this and wanted to test. I wanted to test an upgrade Windows Server 2012R2 AD to Server 2016. In place migration. Yes, I know, it's not really worth it as often when migrating, the system isn't really “clean” with all those Microsoft patches accumulated over the years. And also, you usually deploy a new hardware as old hardware might not have the drivers compatible with Windows Server 2016.

Yes, we're talking about physical domain controller (DC) as in real life it's really not worth it to upgrade a virtual machine running 2012R2 into 2016. Usually, I'd chose the second option, which is just to install Windows Server 2016 as a member server and then add a DC role to it and do the migration of the AD like this, then “downgrading” the 2012R2 DC back to server member, before completely decommission the system from the domain.

The AD Services in Windows Server 2016 brought quite a few new things

Privileged Access Management – This PAM feature allows mitigating security concerns in AD environment which cause by techniques such as pass-the-hash, spear fishing … this is very interesting how it works.

Azure AD Join – This enhances identity experience for businesses. Including benefits such as SSO, access organizational resources, MDM integration etc.

Microsoft Passport – Microsoft Passport is a new key-based authentication approach organizations and consumers that go beyond passwords. This form of authentication relies on a breach, theft, and phish-resistant credentials.

Group Membership Expiration – Windows Server 2016 adds support for group membership expirations, allowing you to add a user to a group for a certain period of time. Very interesting indeed for folks you want to give them access for a limited time period only.

But as I said I was curious as I haven't tried this just yet. So one of my lab DCs which runs as VMs (not physical), will be migrated this way. Currently the VM has the Active Directory Domain Services role installed. I think it has also all 5 FSMO roles as well as I did not bother to separate the roles, to spread them out, to my other DC, which is also running 2012R2. OK, let's kick in the lab and do an Upgrade Windows Server 2012 R2 Domain Controller to Windows Server 2016 with the AD services.

How to Upgrade Windows Server 2012R2 AD to Server 2016 – The steps

The process starts with mounting the ISO and executing the setup.exe > The installer proposes to download the latest updates > Select the image you want to install

Then we'll have a message saying that “Active Directory on this domain controller does not contain Windows Server ADPREP /FORESTPREP updates. Our Windows 2016 ISO image is still attached, so we'll need to change drive letter and do:

E: (our CD-ROM drive letter)

then do a:

cd /support/adprep

and then

adprep.exe /forestprep

You'll need to press letter “c” on your keyboard to validate the command.

Once finished, rinse and repeat. Execute the:

adprep.exe /domainprep

and again validate by pressing the “c” letter on your keyboard. Once done you can click the finish button to start the upgrade process.

Then the process will start the process of upgrading Windows Server 2012r2 to Windows Server 2016 by preserving our Active Directory (AD) services. During the process the system will reboot once (in my case).

Then we simply check that we can successfully login and that our AD is still there.

VCSA 6.5 reset root password

It’s always a very annoying situation when you can’t login into a system anymore because you either don’t know the root password anymore or the system is not able to log you in. The latter can happen if the root mountpoint of the VCSA 6.5 appliance filled up.

As VCSA (vCenter Server Appliance) 6.5 is build on top of Photon OS, you can’t use the same standard procedure you know from Debian, Ubuntu or RedHat. But relax, it’s very simple to reset the root password or clean up a filled up root partition.

First thing to do is to restart your vCenter appliance and wait for the Photon OS Splash screen during boot. 

Hit the letter e to enter the boot menu.

Then change to the GNU GRUB boot menu editor and hit enter.

Next is to add the following string behind the line that starts with linux: rw init=/bin/bash

Hit the F10 function key to boot the changed entry.

Clean up the root partition

In many cases you should check the root partition usage, using the df -h command. Very often the log files grew large and filled up your partition. One well known guy is the audit.log in /var/log/audit. So type ls -sh /var/log/audit to check the file size and rm /var/log/audit/*.log to clean it up.

Reset the root password

If you’re sure that you have to reset the root password, please follow these steps:

passwd 

then enter a strong password twice and remember it.

umount /

reboot -f

It is important to add the -f behind the reboot.