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.

SCCM Client Not Updating the server - Part 2

Following on from this post the fix I decided to use is again, not ideal but it will get the machines talking back to the SCCM server.

The solution was to create a task sequence in Group Policy Preferences.
"Computer Configuration" > "Preferences" > "Control Panel Settings" > "Scheduled Tasks".

Create a new task with the following settings. The most important one is "Run with highest priviledges". Enter the details of an admin account that can run this on the PC's you want it to as well.

Create a new trigger, I went for "At log on", and delayed this by an hour. So after the user has been logged in for an hour, run this task. I also add a limit to how long this can run, just incase.

Create a new action, "Start a program". You want to run:

C:\Windows\System32\ccm\ccmrepair.exe

I have also added a condition that a network connection must be available. There is no point trying to reconnect to the server if it cannot be reached.

The rest of the settings dont really matter, but the above is what I went for. As long as a machine gets Group Policy, the SCCM client will repair.

Still best to resolve the issue with the build as outlined in this post, but this will fix the ones that slipped through the deployment.

Re-install SCCM Client

There comes time when reinstalling the SCCM client on the users PC is needed. I tend to delete the client from the SCCM server before doing this so that a new account is created.

Click > "Start" and type "CMD"
Right click on "cmd.exe" and click "Run as Administrator"

Click Yes or authenticate to run the CMD window as Admin.
NOTE: "Run as administrator" is NOT the same as runing as an administrator account!!

In the command window, type the following:

cd / <enter>
cd \Windows\System32\ccmsetup\ <tab><tab>
 

Where <enter> and <tab> are the enter and tab keys on your keyboard.

This should now show the path including the GUID of the folder and press enter. This is different for every computer.

Type:

msiexec /x client.msi <enter>

The SCCM client will now uninstall. Once removed, run "ccmsetup.exe" again. You cannot install from the MSI. This can be found on the SCCM server, or from the folder:

"C:\Windows\System32\ccmsetup"

Since this silently installs the SCCM client, watch to see when the process "ccmsetup" stops running.

Windows KMS Keys

The Windows KMS keys are generic and basically tell Windows to go and look for your KMS server get get licensed.

Below is Microsofts list of keys to use.

http://technet.microsoft.com/en-us/library/jj612867.aspx

CryptoCard - Outer Window Authentication

Not really deployment related but something I have been scratching my head over today. For a 2nd factor of authentication we run CryptoCard.

CryptoCard is wonderful, the way it works is that it knows what the next X number of possible codes that the shiny dongle of fun will generate (My guess is 3,600 of them).
In the “Policy Admin” screen there are some options for “Syncronization” the important ones are the top 2.

From the Crypto Hand-Book modified to make sense:
INNER EVENT BASED OTP WINDOW SIZE
This represents the number of passwords the server will “Look-ahead” from the last successful logon by the user.
Using an Example, if the user presses the button and does not use that number. The server will be expecting token number 1. But when the user authenticates they use token number 2. The server will look through token codes, 1 through to 10 (the default) and if a match is found they will be authenticated.

OUTER EVENT BASED OTP WINDOW SIZE
When the entered token code is not found in the Inner Event Based OTP Window the server will check the next set of codes up to the limit in the Outer Event Based setting (default 100). If a token code match is found the user will need to resync their token, in admin the web interface this can be seen with the “Result”: “Outer Window Authentication"



Junos Pulse doesnt handle the "Enter Next Token" bit properly and just comes up saying "BAD Passcode" and asks for a response. I tried everything I could think of, same code with and without pin, next code with and without pin and the same for the next 2 screens that come up. No luck.

This leaves us with no real way to resync a token that is in this state. The options are to increase the OTP Window Sizes, or find some way to resync.

I have gone with both... 10 is a bit too few. Especially if the Crytpo box has a problem and users keep trying to login over a weekend.

The 2nd part was to have a way to actually do a resync when it is needed, since the proposed method on a crypto card requires the user to enter challenge codes on a token with 1 button... not ideal. The alternative isnt pretty but will do the job and get them logged in.

On the Crypto Server add the user as an Operator with the lowest privileges (Reporting). They give you the PIN and Token number which you use to login. The login page will prompt again for the login details telling you to enter the NEXT OTP (One Time Passcode).
Enter the username, PIN + Token number. You should see the reporting page. Log out, remove the Operator roles from the user and they can login as them selves from home.

Not ideal to add them to the server as an Operator, but they never attempt the logins (an admin does) and the roles should be removed straight away. Its got us out of a jam in a week that should have been quiet.

SCCM OS Targeting by Collection

In cases like updates and such you may want to target machines based on what OS they are running.
Create a new collection, and select a Query based rule

Give the rule a name, limit it to a collection if you wish. Click "Edit Query Statement..."

On the Query Statement Properties, click "Show Query Language". This will allow you to enter a statement rather than selecting fields manually.

Paste in the the query below, and change the <OSVERSION> with the version number below that.

select SMS_R_SYSTEM.ResourceID,SMS_R_SYSTEM.ResourceType,SMS_R_SYSTEM.Name,SMS_R_SYSTEM.SMSUniqueIdentifier,SMS_R_SYSTEM.ResourceDomainORWorkgroup,SMS_R_SYSTEM.Client from SMS_R_System where SMS_R_System.OperatingSystemNameandVersion like "%<OSVERSION>%"

Windows XP: Workstation 5.1
Windows 7: Workstation 6.1
Windows Server 2003: Server 5.2
Windows Server 2008: Server 6.0
Windows Server 2008 R2: Server 6.1

Save the query and the collection. Update and the collection will now contain all machines that have reported to be running that OS Version.

SCCM Client Not Updating the server

PART 2, the more reliable solution

Post deployment clients are not talking to the SCCM server and updating it with their information.

The blog post here has some great information on how to solve the issue. What it doesnt cover is how to get the PC's you have rolled out already.

What J.C. Hornbeck does mention is where to correct it, the registry key:
HKLM\SOFTWARE\Microsoft\CCM\CcmExec\ProvisioningMode="true"

I have created a Group Policy Preference to change the "true" to a "false". Follow this up with the script from Microsoft here. If you are deploying this out there, comment all the "Echo" commands out so it gives no prompts and is 100% silent.

This is NOT a fix for the root issue, but gets the clients already deployed to comunicate back to the mothership

Remove Domain Group Policy from PC in a Workgroup

Scenario:
You build a PC using you favourite deployment method which adds it to a domain. The PC gets Group Policy but is then removed from the domain.

The computer policies are NOT removed... By design or a design flaw who knows.

Solution:
To remove the policies launch "regedit" and browse to:
"HKLM\Software\Microsoft\Windows\CurrentVersion\Group Policy"
Remove any keys starting with "S-".

Open the key "GroupMembership" and delete the entries starting with "S-" that you removed above.

 

Reboot and you are now policy free.

Canonical Names for Windows 7 Control Panel

Obviously you don't want all users to be able to access every item inside of the Control Panel.

So in Group Policy you can set which items are visible/hidden. To do this in GP go to: "User Configuration" > "Policies" > "Administrative Templates" > "Control Panel"

Edit the policy with the Canonical names of the C Panel items.

http://msdn.microsoft.com/en-us/library/windows/desktop/ee330741(v=vs.85).aspx

The format from what I have seen is:
Default windows items have "Microsoft." at the start and no spaces in the name. For example "Microsoft.WindowsFirewall"
For everything else it is it's name as seen in the C Panel. For example "Configuration Manager" or "Mail"

Stopping Windows 7 UAC for an application

The Windows 7 UAC can be a problem with some older applications when they were made with little thought to how crazy MS could get.

Any exe that has "Setup" or "Install" anywhere in its properties will have UAC ask for elevation. To get around this the "Microsoft Application Compatibility Toolkit" was created.

Download, install and run this (Compatibility Administrator). Once launched, create a new database under "Custom Databases". Right click the DB > "Create New" and select "Application Fix"

Give the whole thing a name, and browse to the application exe that is causing an issue.

Select the Compatibillity Mode for some version of XP (XP SP2/3) and select "RunAsInvoker" under "Additional Compatability modes". This tells Windows 7 that this app should run as the user who launches it... as in, it doesnt need to be an admin.

From the Compatibility Fixes select, "AddWritePermissionsToDeviceFiles" and click Next

Below is the reason my app wouldnt work, "spv-setup"... on the running application file.

Your application database thing should look like this

Once all that is done, copy it somewhere and run the command as an admin. I deployed this via SCCM which manages all that for me. But running it without a full path didnt actually work. So I copied it locally in my install script.

copy "spv.sdb" "c:\spv.sdb"
sdbinst c:\spv.sdb

Restoring a GPO from a file backup

After having GPMC crash on me today I was left with a GPO that I couldnt edit because it was "invalid". "Failed to open the group policy object the data is invalid"

Now I havn't made in backups inside of Group Policy and as such couldn't do a quick restore. What we do have is NetApp backing up the OS drive every hour... should be all I need. Well no, turns out the way to restore when you have the files is an Authorative Restore... shutting down the DC and going through a long winded process.

After some thought into it I came up with a work around. The GPMC works, so I backed up the problem GPO to disk. Inside of this backup is a copy of the files from the OS drive.

Replaced the issue registry.pol with one from the backup and restored it back into Group Policy. This did the trick, its an hour or so old but thats not too bad I hadnt made any changes since. Better than recreating the whole thing from scratch.


To locate the files in your backup restore, you need to get the UID of the GPO. Select the GPO in the GPMC and click the "Details" tab. The UID is highlighted below.

Next browse to:
"X:\Windows\SYSVOL\sysvol\<domain>\Policies\<UID>"
Where X is the drive the restore files are on. Replace <domain> and <UID> with your details.

From here select either "Machine" or "User" for which ever part of the GP got corrupted... or both, or even just use this whole folder. Use these files to replace the corrupted ones in your GPMC backup and do a restore.

To do a backup or restore, right click the policy and follow what it says.

Hope this helps...

DEP and BitLocker

Enabling DEP (Data Execution Protection), or to change it its configuration is done in one of 2 ways.
Through Properties on Computer
Or using the command line "bcdedit /set nx "

Either method will work and do what you want it to (In my case it was OptOut which allows you to specify applications to be exempt from DEP).

The issue comes in when you are running OS disk encryption with BitLocker. Changing DEP settings changes boot.ini and as such will lock the user out of BitLocker requiring them to enter the recovery key until the PIN is changed. Even this may not stop them getting the prompt.

Obviously this isn’t ideal for a mass deployment, where having to manually change the BitLocker PIN for every user means you may as well manually set DEP.

The solution, start and stop BitLocker. 

manage-bde -protectors -disable c
bcdedit /set nx OptOut
manage-bde -protectors -enable c

The above added to a batch script, or SCCM will pause BitLocker (and not prompt for a PIN), changes the setting for DEP in boot.ini and then restarts BitLocker.

When you stop BitLocker is irrelevant, as long as it is restarted AFTER you have made the changes to boot.ini. The same stop and start will be needed for some changes to the BIOS or hardware.