Referenced account is locked out - Domain Admin account

We have a domain (not the main one) where there is a single DC with 1 known Domain Admin account.

For some reason this account became locked. With the only working domain admin account locked we were unable to administer the domain.

There are some pieces of software out there that can reset AD accounts for you but can you really trust them? Luckily there is another solution.

The following blog walks through how to reset the password for the built in domain Administrator account. And how to find this account if it has been renamed.

Before doing this, if you know the password already you can edit the script to use the following:

sc create ResetPW binPath= "%ComSpec% /k net user loginname /DOMAIN /active:Yes" start= auto

http://binarynature.blogspot.co.uk/2013/01/reset-active-directory-administrator-password.html#!/2013/02/find-active-directory-administrator-users-in-dsrm.html

Scripting Compatibility Mode

Due to certain policies we have in place, the compatability wizard is disabled for users. They cant run anything as an admin and cant install software.

With some staff being remote, installing software is a challenge that is normally solved by SCCM deployments. However, doing this for 1 user is overkill in my opinion.

What we would normally do is remote in using SCCM Remote Tools, and run the install as an admin. Great, until the application needs to be run as an old version of Windows. Since you are doing a “run as”, you cant just change the compatability mode using the properties window as this is user specific.

 

There is a environmental variable that can be run, but finding information on it is a little difficult.

__COMPAT_LAYER

 

So the command to use it is:

set __COMPAT_LAYER=

 

Add this at the start of a batch file and everything that comes after is run using the settings used. This didnt work for me when I do "run as another user" on the batch file, but worked fine with "Run as Administrator". Which is fine as I have a tool that allows me to run CMD as Administrator using SCCM.

 Here are some of the options you can use: seperated by a space

Compatibility Mode	Data Value
Windows 95	WIN95
Windows 98 / Windows Me	WIN98
Windows NT 4.0 (Service Pack 5)	NT4SP5
Windows 2000	WIN2000
Windows XP (Service Pack 2)	WINXPSP2
Windows XP (Service Pack 3)	WINXPSP3
Windows Server 2003 (Service Pack 1)	WINSRV03SP1
Windows Server 2008 (Service Pack 1)	WINSRV08SP1
Windows Vista	VISTARTM
Windows Vista (Service Pack 1)	VISTASP1
Windows Vista (Service Pack 2)	VISTASP2
Windows 7	WIN7RTM

 

Settings	Data Value
Run in 256 colors	256Color
Run in 640 x 480 screen resolution	640x480
Disable visual themes	DISABLETHEMES
Disable desktop composition	DISABLEDWM
Disable display scaling on high DPI settings	HIGHDPIAWARE

 

Privilege Level	Data Value
Run this program as an Administrator	RUNASADMIN
Run this program as Invoker	RUNASINVOKER

Network Load Balancer - Disconnecting Interfaces

After reading countless guides on Microsoft Network Load Balancer and none of them making any sense I eventually came across how this should actually work.

Configuring NLB is straight forward. Understanding what is required from the networking was where it got confusing for me, as no one really explained this properly.

For NLB to work, you need 2 network interfaces. 1 is your servers IP address that it is accessed from by other servers / clients on your network. The second is the NLB network, which us used purely for communication between the balanced servers.

The network details:

Actual Server IP range: 10.0.0.0 /24 (255.255.255.0)
Cluster IP Required: 10.0.0.10 /24
NLB IP range: 10.0.1.0 /24

The network that that the 2 interfaces are on MUST be the same. So in VMWare or even physical they should be on the same VLAN. And if both are in the same subnet they should be able to communicate. I will explain more in a sec.

Now give your networks in Windows some names to make them easier to see.

Configure your LAN IP's as you would normally. Once that’s done assign your NLB network an IP address in its range.

So in my example range above your LAN IP would be something like 10.0.0.1 /24. Give your NLB an IP that makes sense, so 10.0.1.1 /24 would be good. Do the same on the next server(s).

Do not set a default gateway or any DNS on the NLB interface.

If you have NLB installed, great. If not... install it. Create your cluster as everyone recommends. Selecting your NLB interface as the dedicated IP, set your cluster address on your server IP range and do the port stuff as you need it.

What I found with my struggles was that if you have the NLB interface on a separate VLAN or network I couldn’t get to the cluster IP from my Server network. If I put the NLB interface onto the Server IP range the 2 interfaces would have IP conflicts and only 1 would work.

This way, there is no conflict. The Cluster IP address belongs to the NLB cluster on your Server IP range and not the interfaces that are on that range. On the NLB network the IP address for the Cluster isn’t accessible from the NLB interfaces so they don’t get affected by the conflict.

Hope this helps anyone scratching their head wondering why NLB isn’t working.

Instructions on how to configure NLB can be found here:

http://technet.microsoft.com/en-us/library/cc754071(v=ws.10).aspx

Recover Data from failing BitLocker drive

A very good write up by Matthew Boyd on recovering data from a failing BitLocker Drive.
http://iboyd.net/index.php/2012/09/08/recovering-data-from-a-failing-bitlocker-hard-drive/

TL;DR version:
Removing the disk drive from the laptop/PC and connecting it via USB to another Win7/8 PC will allow you to attempt to access the data with the Recovery Key.

If this fails or has problems, RIPLinux with DDRescue can make a copy of the data to another disk in the hope that you can gain access to the data from this new disk.

NetApp with Windows based NTP server

Description
Data ONTAP 8 uses NTP for time synchronization. It requires a more accurate time source than that provided by Windows DC by default (10 seconds). Therefore, using Windows DCs, Data ONTAP 8 loses time synchronization. If the time difference between the storage system and the DC is greater than 5 minutes, a CIFS authentication failure will occur.

Procedure
To determine the accuracy specified by the Windows DC, use regedit.exe on the Windows DC to examine the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\Config\LocalClockDispersion

If the value is the following, it can be concluded that the DC is not configured to report itself as a time source with the accuracy required by NTP:

dword:0000000a.

According to article 2015314: Data ONTAP 8 and later releases fail to synchronize time with Windows w32time NTP server, run the following command on the DC to change the reported accuracy to work with Data ONTAP 8:

w32tm /config /localclockdispersion:0 /update

NetApp KB: https://kb.netapp.com/support/index?page=content&id=1013468

PXE-MOF : Exiting Intel boot agent

Recieved the following symptom after bouncing a distribution point which is also the WDS server for a site. Clients trying to PXE boot recieved:

TFTP.

PXE-MOF : Exiting Intel boot agent

This issue was caused by the permissions on C:\Windows\Temp being reset and locked out for everyone.
The result is clients trying to boot from WDS cannot access the files they require.
These are stored in C:\Windows\Temp\PXEBootFiles\Windows\Boot\PXE\

Restarting the WDS service can sometimes resolve it.

However, if this is the permissions issue there is a bit more work involved.

1. Remove the PXE Service Point role from SCCM
2. Remove the WDS role from the server, this will reboot the server.
3. Take ownership of the Temp folder, and reset permissions (include all sub folders and files)
4. Delete the Temp folder
5. Create a new Temp folder
6. Add the WDS role to the server
7. Reboot
8. Add the PXE Service Point role in SCCM
9. Re-add the boot images

Obviously wait on each step to make sure roles are removed especially in SCCM.

Information thanks to: http://grahamhosking.blogspot.co.uk/2011/08/problems-with-pxe-boot.html

SCCM - Enable BitLocker with TPM and PIN

In our environment we are using BitLocker with the TPM and a PIN. SCCM has the option to enable BitLocker as part of a Task Sequence.

However, you cannot set a PIN. Now if you have the settings in Group Policy to force a PIN this wont add the registry settings until AFTER the TS has completed. Not very useful.

The solution:
Use the built in SCCM Task for Enable BitLocker. Choose TPM only and save the recovery info into AD:

This will enable BitLocker and start encrypting the disk. I have not tested it yet, but I cant see why you couldnt have this straight after the step "Setup windows and ConfigMgr". In theory this would leave you much further in the encryption process by the time the TS ends.

From an encrypted PC you want to export the registry with your settings. Remember to re-do this if you change your BitLocker policy. The registry you want is located here:
[HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\FVE]

With this all at the end of the TS, I add a reboot after the above step. I have had some odd results with the first login without doing this reboot. However if this is at the begining, you will most likely have a reboot somewhere.

Apply the registry you exported above, using a "Command Line", or create a package.

regedit /s <filename.reg>

Ok, so we have encryption enabled, and our registry added. Now we can set a PIN. Add another "Command Line"

manage-bde.exe -protectors -add c: -tp %EnPass%

%EnPass% is a task sequence variable. How you set this is up to you, you can set this manually here if you want. I have an HTA with some options, one of which asks for this password and sets this variable.