You should format you shared disks with NTFS before you form you cluster. If not the disks will not be eligible as witness disks. (NTFS is a requirement for a disk witness.) Do not assign a drive letter or mount point to your witness disk. (Disks used e.g. for a clustered file server needs a drive letter assigned. Do this through Failover Cluster Manager.)
If you want to run, say, a clustered file server, the corresponding role must be installed on the nodes of the cluster. This is true for all built-in roles.
To be able to add a share to a clustered file server in Failover Cluster Manager; the Remote Volume Management firewall exception must be enabled on all nodes. To enable this exception from the command line: netsh advfirewall firewall set rule group=”Remote Volume Managmenet” new enable=yes
To move the default cluster group (called Cluster Group by default) with PowerShell: Move-ClusterGroup –Name “Cluster Group” –Node <name of destination node>
To see the owner of the default cluster group with PowerShell (the only way you can actually see that information, to my knowledge (except with cluster.exe, of course)): Get-ClusterGroup “Cluster Group”
As with Windows Server 2008, Windows Search is included as part of the OS and can be installed through Server Manager or PowerShell. Unfortunately it is located in a not quite intuitive place…
To enable Windows Search on Windows Server 2008 R2 you must start the Add Roles wizard and then select File Services Role, on the Role Services page you will find Windows Search:
The Role Service File Server is selected by default, so if you only want Windows Search uncheck it.
I recently upgraded my home network to Forefront Threat Management Gateway (TMG), retiring my old ISA Server 2006 server. I exported my ISA configuration and imported it into TMG, but to be on the safe side I decided to keep a copy of the server as a virtual machine. I used the P2V wizard in System Center Virtual Machine Manager (SCVMM) R2, but after I hit the Scan System button this error appeared:
VMM is unable to complete the request. The connection to the agent <ISA Server FQDN> was lost.
Ensure that the computer <ISA Server FQDN> exists on the network, WMI service and the agent are installed and running and that a firewall is not blocking HTTP and WMI traffic.
ID: 3157
Details: The RPC server is unavailable (0x800706BA)
Preparing to run the P2V wizard I had already created a new access rule allowing all traffic between the SCVMM and ISA Server computers, and disabled the Strict RPC compliance on the rule:
Apparently something was interfering with the RPC communication. Since my P2V rule was at the top of the Firewall Policy whatever was causing the problem had to be in the System Policy. I displayed the System Policy in the Firewall Editor and looked through each rule that specified RPC communication to the ISA Server. Turns out there was only one; the Microsoft Management Console (MMC) rule. To successfully perform a P2V of an ISA Server you need to disable the Strict RPC compliance setting. There was no way to do that in the MMC rule in the System Policy. Since all System Policy rules are processed before the Firewall Rules the MMC rule matched the RPC traffic and blocked parts of it necessary for P2V. I disabled the MMC rule, leaving only my P2V rule. Now the wizard worked correctly.
Windows Deployment Services (WDS) has the ability to search Active Directory for pre-staged computer accounts to use when deploying images. There are several benefits to this, e.g. you can choose to service only known clients that you have created and ignore others, and you don’t have to provide or generate computer names since the image is deployed with the name of the pre-staged account. The information used to match a pre-staged computer account with a PXE-booting client is one of three things; the MAC address of the NIC executing the PXE boot, the GUID of the system or the GUID of the NIC executing the PXE boot. The latter is most widely used and recommended by Microsoft, since it virtually guaranteed to be unique. The WDS server performs an LDAP query to find the account that matches the booting computer:
(&(objectCategory=<DN of Computer Schema object>)(|(netbootGUID=<GUID>)(netbootGUID=MAC)))
This filter ensures that a device will be found if it is pre-staged using either a computer GUID or a MAC address. The netbootGUID attribute on a pre-staged client is used to store the value of the physical computer’s GUID or the MAC address.
You enter the GUID in two ways; using the GUI and Active Directory Users and Computers (ADUC) or using the CLI and WDSUTIL.EXE. Regardless you need to pay attention to how you format the GUID, because GUIDs can be byte-swapped according to the endianism of the system that handles them. The GUI in ADUC hints at this if you enter an invalid value:
————————— GUID Not Valid ————————— The globally unique identifier (GUID) query you entered is not valid. Use one of the following formats to enter a GUID:
0123456789ABCDEFABCDEFABCDEFABCD or
{67452301-AB89-EFCD-ABCD-EFABCDEFABCD} (Note byte reordering) ————————— OK —————————
In this message the first GUID is presented in what is known as binary octet string, the second representation is called just GUID string.
From the message you can work out how to convert between the two.
From Binary Octet string to GUID string (using the octet string in the message above):
Each pair or characters is called an octet. Work with the GUID from left to right.
Take the first 4 octets and reverse their order: 01234567 –> 67452301.
Take the next 2 octets and reverse their order: 89AB –> AB89.
Repeat for the next 2 octets: CDEF –> EFCD
The rest of the octet string is identical for both formats so just add a hyphen: ABCDEFABCDEFABCD –> ABCD-EFABCDEFABCD
Reverse the process to convert from GUID string to binary octet string.
So how do you know which type you have? Sometimes the system will tell you; like ADUC’s Attribute Editor does:
Now, to confuse you completely, take a look at this from the ADUC Attribute Editor:
You have a value that is stored as an Octet String, but displayed in the list as GUID string! You have to double-click the value to see the REAL Octet String! Nice going!
Anyway, back to figuring out which way your GUID is displayed. If the system does not explicitly tell you which type its using I can give you this rule of thumb: GUID strings are usually displayed in braces (squiggly/sexy brackets) and with hyphens, or just with hyphens, while Binary octet string GUIDs are not. Keep in mind though; this might not always be the case. A perfect example of this is PXE boots, where the GUID that is displayed has hyphens, but is still an octet string GUID. All physical machines that I have observed have had octet string GUIDs in their PXE boot screens (see exception below for Hyper-V VMs).
If you want to pre-stage a computer account in Active Directory using this GUID you have to enter it without braces and hyphens:
This will cause ADUC to convert it to a GUID string, which is what the GUI always displays:
A very interesting exception to this is for Hyper-V VM PXE boots. For some strange reason, Microsoft decided that the GUID displayed during PXE boots in a Hyper-V VM is in GUID string format!
If you want to pre-stage a Hyper-V VM in Active Directory using this GUID you have to enter it with braces and with hyphens. This prevents ADUC from converting it, which it would do with a normal (octet string) GUID. So the braces probably mean ‘literal’ string or something.
In smaller deployments Microsoft Security Essentials (MSE) is a good, free alternative for anti-malware. If you decide to use MSE in your images, you will discover that sysprep resets the Out Of Box Experience (OOBE) settings for MSE. In other words; every user that logs on to a machine deployed from your image will see the MSE OOBE Wizard (Figure 1-2), until someone with Administrator privileges completes the wizard. Sometimes you might not want to expose your users to that. Fortunately for us, we can use Group Policy Preferences to bypass the OOBE wizard.
Steps to disable MSE OOBE with Group Policy Preferences:
Create a new Group Policy Object (GPO) or use an existing one.
Create a new Registry preference for computers (Figure 3).
Update the key HKLMSOFTWAREMicrosoftMicrosoft Security EssentialsOOBE DWORD to 0.
Update policy on the client.
The OOBE value has two (known) values:
1: Yes, run OOBE please
0: No thanks, OOBE has already run for this computer
Having shown you how to do this I would like to call attention to the following excerpt from the Microsoft Security Essentials EULA:
INSTALLATION AND USE RIGHTS.
Home Use. If you are a home user, then you may install and use any number of copies of the software on your personal devices for use by people who reside in your household. As a home user, you may not use the software in any commercial, non-profit, or revenue generating business activities.
Small Business. If you operate a small business, then you may install and use the software on up to ten (10) devices in your business.
Restrictions.
The software may not be used on a device running an enterprise version of a Microsoft Windows operating system.
The software may not be used on devices owned by government or academic institutions.
Separation of Components. The components of the software are licensed as a single unit. You may not separate the components and install them on different devices.
Included Microsoft Programs. The software may contain other Microsoft programs. The license terms with those programs apply to your use of them.
The host network adapter does not support the specified virtual network adapter configuration.
Select a host network adapter that supports this configuration.
Remove the check mark for Enable virtual network optimizations on the virtual network adapter in the Hardware Configuration tab of the virtual machine.
RFC 2671 defines the Extension mechanisms for DNS (EDNS), or EDNS0 as it is also known. EDNS is a specification for expanding the size of several parameters of the Domain Name System (DNS) protocol. More info about EDNS here. As of Windows Server 2008 R2, the Windows DNS service will use EDNS in its queries to other DNS servers. Because of the way EDNS works, this should not present a problem. EDNS only adds data to the end of a DNS packet. Any server not supporting EDNS will just ignore those extra bytes and process the first 512 bytes as a regular DNS packet. Unfortunately this is not always so. In some cases, I cannot explain why, DNS servers reject or return an error when they receive an EDNS packet. This could possibly be because the receiving DNS server has some intrusion/hacking functionality in place which causes it to reject a packet longer than 512 bytes, or that it supports the EDNS specification partially. Whichever it is, this presents a problem. The best way to fix it is to update the offending DNS server. This should be easy to do and solve the problem for everybody. If that is not possible we have to disable the EDNS functionality on the Windows DNS servers. To do this you use dnscmd.exe.
The answer received from a non-compliant DNS server when queried using EDNS could generate event 5504 in the DNS log of the Windows DNS server that sent the query. This is an example:
Message : The DNS server encountered an invalid domain name in a packet from <IP address of DNS server>. The packet will be rejected. The event data contains the DNS packet.
It seems that any Windows DNS server upgraded to Windows Server 2008 R2 retain its original settings and does not use EDNS unless specifically configured to do so.
A network trace can reveal if a DNS query uses EDNS. This example is from Wireshark:
Notice the Type: OPT (EDNS0 option). This means the DNS packet uses EDNS. A packet that does not use EDNS will not have any Addition records.
Firewall may sometimes interfere with EDNS packets. The original DNS specification sets a limit of 512 bytes on DNS packet. If a firewall encounters a packet that is longer than 512 bytes (this would be an EDNS packet) it may block it, causing DNS resolution to fail.
In conclusion
The EDNS draft was first published in 1999, and for good reason. DNS is one of the corner stones of the Internet and we really need the functionality provided by EDNS (DNSSEC, for instance, requires EDNS to work). In my mind there is no reason why anyone should not support it, be it DNS servers or firewalls. Microsoft should not be blamed for turning on functionality that we have had almost 10 years to implement.
KB article 958662 explains how to user Windows Server Backup, the new backup software included with Windows Server 2008 and Windows Server 2008 R2, to backup up Hyper-V virtual machines. The article walks you through creating a new Registry value to enable support for the Volume Shadow Copy Service (VSS) provider for Hyper-V. I have put together a command line that does it for you, just copy, paste and run it on your server.
Event logged in the DNS Server log when a query is received for a name that exists in an authoritative zone, but is also on the global query block list:
EventID : 7600
MachineName : lab-dc1.lab.net
EntryType : Warning
Message : The global query block list is a feature that prevents attacks on your network by blocking DNS queries for specific host names. This feature has caused the DNS server to fail a query with error code NAME ERROR for wpad.lab.net. even though data for this DNS name exists in the DNS database. Other queries in all locally authoritative zones for other names that begin with labels in the block list will also fail, but no event will be logged when further queries are blocked until the DNS server service on this computer is restarted. See product documentation for information about this feature and instructions on how to configure it.
Below is the current global query block list (this list may be truncated in this event if it is too long):
wpad
isatap
Source : DNS
A Windows Vista machine has a user called fourthcoffeejoberry logged on. Another user, fourthcoffeehenrikjensen logs on with Remote Desktop.
fourthcoffeehenrikjensen receives this message, and presses Yes:
The logged on user, fourthcoffeejoberry will see this popup on her desktop and press OK:
While fourthcoffeehenrikjensen waits for fourthcoffeejoberry to respond, this message is displayed in his Remote Desktop window:
fourthcoffeejoberry will be disconnected from her session and the screen on the Windows Vista machine will display Press CTRL+ALT+DELETE to log on:
If she presses Ctrl+Alt+Del she will see that she is just disconnected and not logged of:
The currently logged on user, fourthcoffeehenrikjensen can also see this if he opens Task Manager and displays processes from all users:
fourthcoffeehenrikjensen logs off from Remote Desktop, fourthcoffeejoberry can now press Ctrl+Alt+Del and log in again.
If fourthcoffeejoberry tries to log on before fourthcoffeehenrikjensen has logged of, the process happens in reverse.
fourthcoffejoberry presses Ctrl+Alt+Del and logs on, she receives this message:
The prompt is presented to fourthcoffeehenrikjensen (logged on via Remote Desktop):
While waiting for fourthcoffeehenrikjensen to reply, this message will display on fourthcoffeejoberry’s desktop:
fourthcoffeejoberry is logged on to her session and sees her desktop as it was when she was disconnected. fourthcoffeehenrikjensen is also still logged on. He has to reconnect, disconnecting fourthcoffeejoberry temporarily, to log off from his session.
