Category Archives: Windows

Exchange, Windows

Active Directory recycle bin

1 Comment

I was under the impression I blogged about this years ago (while working on an Exchange 2010 –> 2016 migration) but I couldn’t find my own blog, so here it goes (again).

The Active Directory Recycle Bin saved my life a couple of times, not only my life but also my customer’s life. With the Active Directory Recycle Bin you can restore deleted object from Active Directory, and when using Azure AD Connect also automatically restore object in Azure Active Directory (assuming the deleted object was synchronized before the actual deletion of course).

 Too bad that’s it disabled by default, but enabling the Active Directory Recycle Bin to just a matter of start the Active Directory Administrative Center, select and right-click your root domain and select ‘Enable Recycle Bin…” as shown in the following screenshot:

Of course, it is also possible to enable this using PowerShell, just execute the following commands:

PS C:\> Import-Module ActiveDirectory
PS C:\> Enable-ADOptionalFeature "Recycle Bin Feature" -Scope ForestOrConfigurationSet -Target "ProExchangeAdmin.com"
WARNING: Enabling 'Recycle Bin Feature' on 'CN=Partitions,CN=Configuration,DC=ProExchangeAdmin,DC=com' is an irreversible action! You will not be able to disable 'Recycle Bin Feature' on 'CN=Partitions,CN=Configuration,DC=ProExchangeAdmin,DC=com' if you proceed.
 
Confirm
Are you sure you want to perform this action?
Performing the operation "Enable" on target "Recycle Bin Feature".
[Y] Yes  [A] Yes to All  [N] No  [L] No to All  [S] Suspend  [?] Help (default is "Y"): y
PS C:\>

Wait until all Domain Controllers have replicated this change and you are all set.

But how does this work under the hood? Deleted object don’t stay in the recycle bin forever. By default, a deleted object continues to exist in Active Directory for 180 days, which is set on the msDS-deletedObjectLifetime attribute of the Directory Service object. On the object that is deleted, the isDeleted and isRecycled property come into play.

When a user object is deleted, the isDeleted property on the user is set to True. At this point it is logically deleted, but physically still available in Active Directory (in the Deleted Items container) and it can be restored. When the deleted object lifetime has passed, the isRecycled property is set to True and the Active Directory garbage collector knows it can remove this object from Active Directory (physically removed from the database).

This is graphically shown in the following figure.

It is possible to increase the deleted object lifetime by stamping a higher value on the msDS-DeletedObjectLifetime property. For example, to increase the default lifetime of 180 days to 2 years (=730 days) you can use the following PowerShell command:

PS C:\> Set-ADObject -Identity "CN=Directory Service,CN=Windows NT,CN=Services,CN=Configuration,DC=ProExchangeAdmin,DC=COM" -Partition "CN=Configuration,DC=ProExchangeAdmin,DC=COM" -Replace:@{"msDS-DeletedObjectLifetime" = 730}

Restoring a deleted object from the recycle bin is easy. Open Active Directory Administrative Center, navigate to your domain and select deleted objects. Select and right-click the object and select Restore as shown in the following figure:

It is also possible to use PowerShell to restore a deleted object. For example, to find the user in the previous example we can use the following Powershell command:

PS C:\> Get-ADObject -Filter 'samaccountname -eq "Johns"' -IncludeDeletedObjects

Deleted           : True
DistinguishedName : CN=Labs | John Smith\0ADEL:7ee41efd-0034-46d7-9313-62360fff43fb,CN=Deleted Objects,DC=labs,DC=local
Name              : Labs | John Smith
                    DEL:7ee41efd-0034-46d7-9313-62360fff43fb
ObjectClass       : user
ObjectGUID        : 7ee41efd-0034-46d7-9313-62360fff43fb

PS C:\>

Pipe this output to the Restore-ADObject command and the deleted user will be restored.
Very simple and very useful, I always recommend enabling this.

Windows

ADFS Web Application Proxy Configuration Wizard fails with trust certificate error

3 Comments

I was installing a new ADFS environment on Windows 2022 and the Web Application Proxy Configuration Wizard failed with the following error message:

Retrieval of proxy configuration data from the Federation Server using trust certificate with thumbprint <thumbprint> failed with status code ‘InternalServerError’

The certificate as mentioned the wizard is available on the WAP server. You can check this using the following command in PowerShell:

PS C:\> Dir CERT:\LocalMachine\My

For some reason, the WAP server is having difficulties contacting the internal ADFS server which is also running on Windows 2022. Name resolution works fine and credentials of the local administrator were ok.

One of the new features of Windows 2022 is support for TLS 1.3 and here’s the culprit. It seems like ADFS is not working correctly with TLS 1.3.

To disable TLS 1.3 on the WAP server, add the following registry keys:

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3]

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Client]
"DisabledByDefault"=dword:00000001
"Enabled"=dword:00000000

[HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\SecurityProviders\SCHANNEL\Protocols\TLS 1.3\Server]

As shown in the following screenshot:

After adding these registry keys, the WAP Proxy configuration wizard finished successfully.

Windows

Transfer FSMO Role Win32 error returned is 0x20af

1 Comment

For a client I had to test some domain controller scenarios and issues. There are two domain controllers (DC01 and DC02) and a new one (NewDC) is added. FSMO roles are moved to NewDC and DC01 must be decommissioned. No big deal you would say….

Domain FSMO roles (RID Master, PDC and Infrastructure master) moved in an instant, but moving the forest FSMO roles (Schema master and Domain Naming master) failed with the following error, both in the GUI as well as NTDSUTIL:

Win32 error returned is 0x20af(The requested FSMO operation failed. The current FSMO holder could not be contacted.)
Depending on the error code this may indicate a connection, ldap, or role transfer error.

Using Netdom query FSMO I could see the roles.

This happened when logged on the AD01 as well as NewDC, connectivity was not an issue and I did not notice any strange issues with Exchange and Outlook or OWA clients.

Using Google I found several other similar issues, and the overall recommendation was to seize the FSMO roles. Seizing FSMO roles is an option when the old Domain Controller is no longer available, but in my scenario I had to keep the old Domain Controller for testing.

But instead of using Google I had to look in the eventlog in the first place. The first entry I found was a confirmation that the roles could not be transferred, but Additional Data Error value: 4 was not very helpful:

An attempt to transfer the operations master role represented by the following object failed.

Object:
CN=Partitions,CN=Configuration,DC=msexchangebook,DC=com
Current operations master role:
CN=NTDS Settings,CN=DC01,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=msexchangebook,DC=com
Proposed operations master role:
CN=NTDS Settings,CN=NIEUWEDC,CN=Servers,CN=Default-First-Site-Name,CN=Sites,CN=Configuration,DC=msexchangebook,DC=com

Additional Data
Error value:
4

Subsequent entries were more helpful, Event 2019, ActiveDirectory_DomainService indicated replication issues:

Or in tekst for Search Optimization:

This server is the owner of the following FSMO role, but does not consider it valid. For the partition which contains the FSMO, this server has not replicated successfully with any of its partners since this server has been restarted. Replication errors are preventing validation of this role.

Operations which require contacting a FSMO operation master will fail until this condition is corrected.

FSMO Role: CN=Partitions,CN=Configuration,DC=msexchangebook,DC=com

User Action:

  1. Initial synchronization is the first early replications done by a system as it is starting. A failure to initially synchronize may explain why a FSMO role cannot be validated. This process is explained in KB article 305476.
  2. This server has one or more replication partners, and replication is failing for all of these partners. Use the command repadmin /showrepl to display the replication errors. Correct the error in question. For example there maybe problems with IP connectivity, DNS name resolution, or security authentication that are preventing successful replication.
  3. In the rare event that all replication partners are expected to be offline (for example, because of maintenance or disaster recovery), you can force the role to be validated. This can be done by using NTDSUTIL.EXE to seize the role to the same server. This may be done using the steps provided in KB articles 255504 and 324801 on http://support.microsoft.com.

The following operations may be impacted:
Schema: You will no longer be able to modify the schema for this forest.
Domain Naming: You will no longer be able to add or remove domains from this forest.
PDC: You will no longer be able to perform primary domain controller operations, such as Group Policy updates and password resets for non-Active Directory Domain Services accounts.
RID: You will not be able to allocation new security identifiers for new user accounts, computer accounts or security groups.
Infrastructure: Cross-domain name references, such as universal group memberships, will not be updated properly if their target object is moved or renamed.

In the end it turned out that DNS was not configured correctly, hence the replication issues. Fixed the DNS settings on the Domain Controllers and after a short while the Domain Controllers resumed replication and I was able to move the Forest FSMO roles to the new Domain Controller.

So in short, always check eventlog, replication and DNS when troubleshooting Domain Controller issues 😉

Windows

Windows Update could not search for new updates when using WSUS

Leave a comment

For testing purposes, I had to install a few Windows 7 and Windows 10 machines (with Office 2007, Office 2010 and Office 365 ProPlus) at a customer environment. It was a standard environment with a regular WSUS environment. In this customer environment there were approx. 5000 clients with Windows 7 (I know…) and Windows 10 all working fine with WSUS.

Several of my test machines had problems downloading updates from the WSUS environment, Windows Update returned the Code 80072F8F Windows Update encountered an unknown error as shown in the following screenshot:

Windows could not search for new updates

Emptying the C:\Windows\SoftwareDistribution and restarting the Windows Update service did not help.

When using Google to search for this error a lot was returned (even recent issues which is the reason for my blogpost), but most of them were certificate related where the self-signed certificate on the WSUS server was expired. In my scenario this was not a problem since a valid 3rd party certificate was used on the WSUS server.

The WindowsUpdate.log in C:\Windows revealed more information. One thing I found was DownloadFileInternal failed for https://wsus.contoso.com:8531/selfupdate/wuident.cab: error 0x80072f8f.

When using a browser to navigate to this URL a got a certificate warning (which I did not expect btw) about verifying the certificate: This certificate cannot be verified up to a trusted certification authority as shown in the following screenshot:

This certificate cannot be verified up to

From this point on it was easy, install the intermediate and root certificate in the certificate store of the workstation and Windows Update ran successfully – although it takes a very long time to deploy all updates, especially on Windows 7 with Office 2010 🙂