Useful References for Intel NIC Teaming on Windows Server Core 2008

1) Enable Remote MMC
To remote MMC console to a standalone (non-domain) computer, add a temporarily administrator account on the target server core that share identical account name and password on another full GUI computer (e.g. Win7, Full Win2K8R2 etc).

Use "sconfig" on the server core to add a local admin account (option 3) and to enable remote administration (option 4).

To perform remote execution,
"winrs -r:%servername% remote command" and press on "Enter" button.

Example: To review remote file system, write the following command:
"winrs -r:DC1 dir"

2) Intel NIC teaming on Server Core

http://www.intel.com/support/network/sb/CS-029966.htm
To extract all Intel NIC inf driver files, use PROWinx64.exe /e /f [destination path] 

3) Enable remote device driver management for Server Core

http://www.petri.co.il/remotely-manage-devices-windows-server-2008-core.htm

4) Configuring system variable environment on Server Core

WMIC Environment where name='Path' SET VariableValue='%ProgramFiles%\Apps;%PATH%'

5) Using PowerShell to manage Windows Features and Server Roles
http://blogs.msdn.com/b/powershell/archive/2009/01/27/managing-server-features-with-powershell-cmdlets-on-windows-2008-server-r2-beta.aspx

6) Enable Jumbo Frames
http://blog.allanglesit.com/2010/03/enabling-jumbo-frames-on-hyper-v-2008-r2-virtual-switches/

7) Enable VMDq on Intel Team for VLANs in Hyper-V
http://www.intel.com/support/network/sb/CS-030993.htm

8) Disable Dynamic DNS update of Hyper-V cluster name
If you have configure static DNS record for the cluster name, you have to disable DNS dynamic update. However, disabling on DNS client update on GPO won't work for cluster name. You have to disable it on the updating interface. Since ncpa.cpl is not supported on server core, use "netsh interface" command and set dnsserver register to none. Example:

To turn off DNS register:
netsh interface ipv4 set dnsserver name="Local Area Connection" source=static address="10.10.10.1" register=none

To add another DNS server
netsh interface ipv4 add dnsserver name="Local Area Connection" address="10.10.10.2"

Part 5: Sysprep and Capture Server Image using MDT2010

In the part 4, I mentioned about using MDT2010 to perform Windows installation over the network share. After you have installed, configured and patched this reference computer, you may like to "clone" this image for subsequent server deployment.   

You may use MDT2010 to sysprep and capture this reference image. Initially, I thought of doing a PXE boot and capture the image after creating a new task sequence for sysprep and capture. But I was half-right. Instead, after creating the new task sequence, you have to login to your reference computer, map to the MDT network share and execute the sysprep and capturing LTI scripts as follows:

cscript \\mdtserver\DeploymentShare$\Scripts\LiteTouch.WSF

For step-by-step details, please click on "How to run a Sysprep and Capture Task Sequence from MDT2010".

AD authentication for Dell iDRAC6

The well-known default login name and password for iDRAC6 are "root" and "calvin" respectively. You should change it immediately, which may probably turn into accountability issues of having shared password among various administrators. A better way is to configure it to permit AD authentication that allows individual login accounts and ensures consistent password policies.

Step 0: Configure IP and DNS settings on iDRAC

Step 1:Enable Microsoft Active Directory on "Directory Service" under "Network/Security"

Step 2: Enable cert validation and upload the Enterprise CA cert.

Step 3: Choose Standard Schema

Step 4: Enter the fqdn of domain controllers e.g. dc1.domain.com. Define the user groups on AD and authorize appropriate rights accordingly.

 

Step 5: Lastly, test the settings. Supply the test account name using "user@domain.com" format instead of "domain\user" format that won't work.

Enrolling SSL Cert for DELL iDRAC6

Dell's integrated light-out (ILO) management iDRAC6 allows administrators to manage servers remotely (using Java-based virtual console), as though they were in front of the console physically. Think of it like IP KVM. Managing iDRAC is performed over web console. Most likely, you would be greeted by SSL warnings, which is using a default self-signed cert. To do away with these prompts permanently, you would have to setup a PKI within your enterprise network, such as Active Directory Certificate Services (AD CS).

In AD CS, you should be using Web enrollment to generate certificate for entities outside of AD, such as iDRAC. Create a new web server based template and allows iDRAC users to enroll. Next, generate a cert request for iDRAC. To do so, login to manage iDRAC setting and click on Network/Security and SSL as shown below:

Click on "Generate Certificate Signing Request (CSR)" and download a text-based file. Open this file with a notepad or wordpad. Logon to the web enrollment service e.g. http://certservername/certsrv. Click on "Request a certificate" and "Submit a certificate request".

Focus back on the notepad, copy the contents of the csr and paste it on the certificate request. Select the appropriate cert template.

Click "Submit" and download the server cert. Upload this cert via the same SSL web console page on iDRAC setting earlier. And iDRAC will take a few minutes to reset itself. If you still see SSL errors, take a look and troubleshoot. Most likely, it's due to some typo errors that causes a mismatch between Common Name and the DNS name.

Debugging JUNOS for Cisco dude

In Cisco IOS, you would use debug statement for troubleshooting. How would you do it in JUNOS?

For example, if you were troubleshooting SNMP in Cisco IOS, you would do this:
#debug snmp detail
#term mon

As for JUNOS,
> edit
# edit snmp
# set traceoptions flag all
# set traceoptions file debug-snmp
[Unlike Cisco IOS, you need to commit the changes first]
# top
# commit
[It will start the debugging in next statement]
# run monitor start debug-snmp
[Lots of debugging messages and when you're done, stop it]
# run monitor stop
# delete snmp traceoptions
# commit

Use BGP maximum-paths eibgp with Caution

Under the BGP command process, "maximum-paths" enables BGP to perform load-sharing among multiple paths. There are 3 options:

1. maximum-paths: only allow equal-cost path load-sharing
2. maximum-paths ibgp: enable both equal-cost and unequal-cost path load-sharing for internal BGP
3. maximum-paths eibgp: enable both equal-cost and unequal-cost path load-sharing for both internal and external BGP

If you have 2 or more edge BGP routers on same AS and is using both iBGP and eBGP, use the "maximum-paths eibgp" with caution. The Cisco routers would assign iBGP routes with same administrative distance (i.e. 20) as eBGP. You could end up with a routing loop if you design eBGP to be preferred over iBGP paths.

Part 4: Lite-Touch Installation using MDT 2010 and WDS

Earlier in Windows Deployment Part 1, I mentioned about using WinPE and ImageX (with a network share) to build, capture and deploy OS images. Using the Windows DISM tool, you can also service the OS images whenever you need to update any application patches or drivers. This is a heavy imaging method and is tedious to manage in a long run. In part 2, I mentioned about using Windows Deployment Services to automate the OS image deployment. However, this method alone does not allow you to service your images or install applications automatically. Nevertheless, Microsoft calls both methods as "Heavy-Touch" installation.

Microsoft Deployment Toolkit (MDT) 2010 allows you to combine both methods (WinPE/ImageX and WDS) for Lite-Touch Installation (LTI). This toolkit automates the manual tasks for WinPE and ImageX processes. It also facilitates the new "thin image" deployment concept. "Thin image" deployment does not include all applications and drivers on the base OS image, as constrasted to the traditional "heavy image" approach. Instead, new applications, patches and drivers are installed dynamically when you perform OS deployment.

There are several good blog posts that show you the step-by-step. I found these series of blog posts particularly helpful. In summary, I would just mention the typical overall steps:

1. Prepare the necessary infrastructure, including AD, DNS, DHCP, WDS and file servers.
2. Download Windows AIK and MDT2010. Install them on a technician computer.
3. Open up the Deployment Workbench. Create a deployment share.
4. Import Operating System. Try not to use WDS images option. See this forum.
5. Create a task sequence and follow the wizard. Typically, it's "Standard Client Task Sequence" for new deployment.
6. Add the necessary applications and third-party device drivers.
7. Update Deployment Share by right-clicking on the "MDT Deployment Share"
8. Several files will be created on the network share. Add the newly created boot image to your WDS server.
9. PXE boot your target computer (can be a VM for initial testing). Select the Lite Touch boot option.
10. Resolve all installation errors (if needed). Thoroughly test the target computer.
11. Upon successful deployment, you can choose to create another Task Sequence to sysprep and capture the image, which is completely optional (good for hybrid Thin-Thick imaging). You can use this new capture image for subsequent WDS deployment.