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.