windows-server-2008-r2 interview questions

Top windows-server-2008-r2 frequently asked interview questions

"Unable to open the Server service performance object."

I have a group of servers which all show these symptoms. Every 2-7 days twice in a row, the following error shows up in the Application event log:

Unable to open the Server service performance object. The first four bytes (DWORD) of the Data section contains the status code.

The first four bytes are 34 00 00 C0. Event ID is 2004.

Googling for this always leads to this document on the Microsoft site:


However, it claims that to resolve the issue one has to "Restart the Server service".

The "Server" service is always running and to my knowledge has never ever not worked on any of those servers.

Any ideas?

Source: (StackOverflow)

Is there any reason why TLS 1.1 and 1.2 are disabled on Windows Server 2008 R2?

Windows Server 2008 R2 seems to support TLS 1.1 and 1.2 but they are disabled by default.

Why are they disabled by default?

Do they have any drawbacks?

Source: (StackOverflow)

Phones on some switches cannot complete DHCP process


I have a Windows DHCP server (Server 2008 R2) handing out addresses for several scopes. One of those scopes is for some Mitel IP Phones. The phones are configured to use dhcp option 125 to get configuration information. When a phone starts up, it doesn't know what vlan to use, and so it just gets the default (untagged) vlan of whatever port it's connected to. The dhcp server gives it a response that includes option 125 information, and the phone is able to read what vlan it should use from this response. The phone then releases its original address and requests a new dhcp lease using the correct vlan tag. The phones also usually have computers connected to a pass-through port. The packets from the computers are never tagged, and so the PCs will stay on the original (untagged) vlan for the port. This has worked for us for years.

Problem and Symptoms

Somewhere in the last several weeks, something changed, and I'm not sure what. The phones will continue to work as long as they do not restart, meaning dhcp renew requests must be processed correctly. Phones connected to certain switches can even a survive a restart. Phones connected to other switches, however, will fail to complete the process when they reboot. All of our phones are using PoE that is backed up by a UPS, so it's been a long time since any have restarted. This means I have no idea when the problem first appeared. What I do know is that one phone failed when it restarted yesterday, and in troubleshooting it today we reset that switch closet. Now none of the phones on that switch are working (thankfully it's still a small number). I also know that things were working near the end of the January, when we moved a phone for an injured user to a temporary workspace on the ground floor.

As I watch a phone boot up, I can see it successfully get the first address. It then successfully reads the option 125 information, sets the correct vlan tag, and releases the original IP lease. It is even able to receive and accept an offer on the correct vlan from the server. However, that's where things stop. The phone has a message on the screen that says, "DHCP: Offer 2 ACC", but the Windows DHCP server has not recorded the lease and the phone never moves on. I can only guess that the DHCP REQUEST packet never reaches the Windows server, and so the phone is waiting for the final ACK from Windows that it's okay to continue.


I was finally able to get a phone working again. To do it, I had to first disconnect the computer. Then I set the phone's switch port to be untagged on the phone vlan, with no membership on the PC vlan. The phone will now reboot correctly. At this point, I can put the switch port configuration back where it should be, and as long as no one tries to call that number as I'm resetting the port, the phone never misses a beat. Then I can reconnect the computer. Obviously, that's not an ideal process, though since phones reboot so rarely I will be able to use it to get people working again until I can find the root cause. Offices are closed now for the week, and so this issue will actually be allowed to sit over the weekend (I don't have keys for individual offices where the phones are).

This phone I fixed is the service phone in the server room, connected directly to our core switch. It is possible the problem is an issue with routing or processing tags on the core switch, such that the workaround will not be effective on the remote offices where packets are first passed through (tagged by) other switches, but I'll be very surprised if that happens, given that I know it must be processing dhcp renewals and actual phone conversations correctly.

A twist is that leaving the port tagged on the PC vlan means that phone instead fails with the message "DHCP: Offer 1 ACC". I need to remove that vlan entirely for this to succeed.

Note: I have now confirmed that the work-around is effective in remote buildings. This leads me to suspect that my devices are somehow not assigned to the correct vlan. That fact that I experienced the problem on my core switch, and that it happened in several places on the network at about the same time, indicates that the core switch may be the problem. With nothing specific to look at, I'm scheduling a maintenance window near the end of the week to reboot the switch. I may also update the firmware.


Our core switch is an HP 5406zl. This switch handles inter-vlan routing. The Windows DHCP server is connected directly to the switch. Endpoint switches are connected to the core switch via fiber SFPs, and these ports are tagged for all vlans on both ends. The core switch configures each vlan with an ip helper-address setting that points it to our DHCP server, and a dhcp relay-option 82 replace line so that the dhcp server will know what scope to use. These configurations, and the port configurations on the endpoint switches, have not changed in at least 16 months. We have had other switch and phone resets in that time.

Most of our endpoint switches are HP 2530 series. These switches seem to work correctly (phones on 3 different 2530's have restarted correctly today). It's older switches that have problems. We have one old 3Com 4200 and one 4210 that will not work. The service phone connected directly to the core switch mentioned earlier also would not work.


At this point my best guess is that a Windows update on the dhcp server changed the behavior, but I can't see how. Or possibly the core switch is not handling that REQUEST packet correctly, but I'm sure that nothing changed there, and it doesn't explain why only certain endpoint switches are effected. How can I resolve this issue?


Here is a dhcp log excerpt from a failed phone:

10,03/06/15,12:40:40,Assign,,,08000F197844,,3189088995,0,,, 11,03/06/15,12:40:40,Renew,,,08000F197844,,3189088995,0,,, 12,03/06/15,12:40:41,Release,,,08000F197844,,3189088995,0,,, 15,03/06/15,12:40:45,NACK,,,08000F197844,,0,6,,, 15,03/06/15,12:40:45,NACK,,,08000F197844,,0,6,,,

The 10.x.x.x addresses are the PC vlan (that choice pre-dates me at this place). Phones should get that kind of address at first, so that's expected. However, after the release message I also expect to find an offer for an address in the 192.168.16.x range, because I can see on the phone that an offer was accepted (unless I'm misinterpreting "ACC"). It's interesting that I never see the server try to issue an address like that, even though the phone thinks it received one.

I considered the idea there's a rogue dhcp server on the network (it hands out an address before the Windows server, but without the dhcp options needed by the phone to continue), but that doesn't explain why the phones work if and only if I completely remove any path to the PC vlan. I'll test for it anyway in the morning by connecting my laptop to a port set for the phone vlan, but if anyone else has a better explanation in the meantime, I'd love to hear it.

Here's a copy of the switch config:


Source: (StackOverflow)

What are the implications of enabling the Recycle Bin feature in Active Directory?

An admin accidentally deleted the wrong OU and it removed several account and computer objects. The recycle bin optional feature was not enabled. We used adrestore from sysinternals to get the accounts back.

To ensure this process is easier the next time we wanted to enable the Recycle Bin optional feature which is easily done as per guides and TechNet using Enable-ADOptionalFeature via PowerShell.

In both PowerShell and the above link the following is mentioned.

In this release of Windows Server 2008 R2, the process of enabling Active Directory Recycle Bin is irreversible. After you enable Active Directory Recycle Bin in your environment, it cannot be disabled.

In theory I would always want to leave it enabled but I have hesitated until I understand the implication of what is about to happen. I have a single domain forest if it matters.

What is the implication of enabled this feature? This must relate to why it is not enabled by default.

Source: (StackOverflow)

Domain Controller thinks its on a Public Network

We have a Server 2008 R2 Primary Domain Controller that seems to have amnesia when it comes to working out what kind of network it is on. The (only) network connection is identified at startup as a 'Public Network'.

Yet, if I disable and then re-enable the connection, it happily figures out that it is actually part of a domain network.

Is this because AD Domain Services is not started when the network location is initially worked out?

This issue causes some headaches with Windows Firewall Rules (which I am more than aware can be solved in other ways) so I am mostly just curious to see if anyone knows why this happens.

Source: (StackOverflow)

How to enable TLS 1.1, 1.2 in IIS 7.5

We want to support web browsers utilizing TLS 1.1 and 1.2, which has been apparently implemented by Microsoft, but is turned off by default.

So I went searching on Google and discovered some pages everyone seems to be following:



However! It doesn't appear to be working for me. I have set both DWORD vaules for DisabledByDefault and Enabled for TLS 1.1 and 1.2. I can confirm my client is attempting to communicate with TLS 1.2, but the server only responds with 1.0. I've restarted IIS, but it didn't change the situation.

Microsoft points out: "WARNING: The DisabledByDefault value in the registry keys under the Protocols key does not take precedence over the grbitEnabledProtocols value that is defined in the SCHANNEL_CRED structure that contains the data for an Schannel credential."

Well, that's very vague to me. I can't find anywhere where SCHANNEL_CRED is defined or set, all I can determine that it's a structure defined in a Microsoft library. That's my only guess for why this isn't work, yet I can't find enough information on it to determine if it is the true problem.

Source: (StackOverflow)

Process runs slower as a scheduled task than it does interactively

I have a scheduled task which is very CPU- and IO-intensive, and takes about four hours to run (building source code, if you're curious). The task is a Powershell script which spawns various sub-processes to do its work. When I run the same process interactively from a Powershell prompt, as the same user account, it runs in about two and a half hours. The task is running on Windows Server 2008 R2.

What I want to know is why it takes so much longer to run as a scheduled task - more than an hour longer. One thing I noticed is that the task scheduler runs at Below-Normal priority, so when my task starts, it inherits the same lowered priority. However, I've updated the script to set the Powershell process priority back to Normal, and it still takes just as long.

Anybody have an idea what could be different between the two scenarios? I've ruled out differences in processor and IO load - this task is the only thing the system is used for, so there's nothing else running that could be competing for resources.

Source: (StackOverflow)

Should I install Windows Management Framework 3.0?

I'm posting this as a BIG CAVEAT to everyone. I know it's not a standard Q&A, but I think this is something every Windows admin should know. There is a very real risk of falling into Big Troubles.

Microsoft has recently released Windows Management Framework 3.0 for Windows Server 2008 and Windows Server 2008 R2 systems, which includes some nice things native to Windows Server 2012 (like PowerShell 3.0) and lots of improvements to WMI, WinRM and other management technologies.

Windows Update is advertising it as an optional update.

Should I install it on my servers?

Update: Microsoft has removed the update from Windows Update after major compatibility issues with various products (including the ones being discussed here) have been reported by multiple users.

Source: (StackOverflow)

Clear the Recycle Bin For All Users in Windows Server 2008 R2

What is the proper way to clear the recycle bin for all users in Windows Server 2008 R2?

Source: (StackOverflow)

Disable CPU Scaling in Windows Server 2008 R2

How do you disable CPU power management scaling in Windows Server 2008 R2?

After setting the Control Panel, Power Management plan to performance and then rebooting -- CPUID's Cpu-Z still shows the clock speed being scaled.

alt text

Source: (StackOverflow)

Send ctrl-alt-del to nested RDP session

Is there a way to send the ctrl-alt-del command to an RDP session (W2K8 R2) inside another RDP session (W2K8 R2) without the fist session catching it?

ctrl+alt+end and ctrl+alt+shift+end do not reach the 2nd level session.

Edit: Top-level environment is Windows 7 Ent.

Source: (StackOverflow)

Windows Server 2008 R2 network adapter stops working, requires hard reboot

TL;DR version: Turns out this was a deep Broadcom networking bug in Windows Server 2008 R2. Replacing with Intel hardware fixed it. We don't use Broadcom hardware any more. Ever.

We have been using HAProxy along with heartbeat from the Linux-HA project. We are using two linux instances to provide a failover. Each server has with their own public IP and a single IP which is shared between the two using a virtual interface (eth1:1) at IP:

The virtual interface (eth1:1) IP is configured as the gateway for the windows servers behind them and we use ip_forwarding to route traffic.

We are experiencing an occasional network outage on one of our windows servers behind our linux gateways. HAProxy will detect the server is offline which we can verify by remoting to the failed server and attempting to ping the gateway:

Pinging with 32 bytes of data:
Reply from Destination host unreachable.

Running arp -a on this failed server shows that there is no entry for the gateway address (

Interface: --- 0xa
Internet Address      Physical Address      Type         00-26-88-63-c7-80     dynamic         00-15-5d-0a-3e-0e     dynamic         00-21-5e-4d-45-c9     dynamic         00-15-5d-00-b2-0d     dynamic         00-21-5e-4d-61-1a     dynamic         00-21-5e-4d-2c-e8     dynamic         00-21-5e-4d-38-e5     dynamic         00-15-5d-00-b2-0d     dynamic         00-15-5d-0a-3e-09     dynamic         ff-ff-ff-ff-ff-ff     static            01-00-5e-00-00-16     static           01-00-5e-00-00-fc     static             01-00-5e-00-00-01     static

On our linux gateway instances arp -a shows:

peak-colo-196-220.peak.org ( at <incomplete> on eth1
stackoverflow.com ( at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-215.peak.org ( at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-219.peak.org ( at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-222.peak.org ( at 00:15:5d:0a:3e:09 [ether] on eth1
peak-colo-196-209.peak.org ( at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org ( at 00:21:5e:4d:2c:e8 [ether] on eth1

Why would arp occasionally set the entry for this failed server as <incomplete>? Should we be defining our arp entries statically? I've always left arp alone since it works 99% of the time, but in this one instance it appears to be failing. Are there any additional troubleshooting steps we can take help resolve this issue?


I added a static arp entry for testing on one of the linux gateways which still didn't help.

root@haproxy2:~# arp -a
peak-colo-196-215.peak.org ( at 00:21:5e:4d:61:1a [ether] on eth1
peak-colo-196-221.peak.org ( at 00:15:5d:00:b2:0d [ether] on eth1
stackoverflow.com ( at 00:21:5e:4d:45:c9 [ether] on eth1
peak-colo-196-219.peak.org ( at 00:21:5e:4d:38:e5 [ether] on eth1
peak-colo-196-209.peak.org ( at 00:26:88:63:c7:80 [ether] on eth1
peak-colo-196-217.peak.org ( at 00:21:5e:4d:2c:e8 [ether] on eth1
peak-colo-196-220.peak.org ( at 00:21:5e:4d:30:8d [ether] PERM on eth1

root@haproxy2:~# arp -i eth1 -s 00:21:5e:4d:30:8d
root@haproxy2:~# ping
PING ( 56(84) bytes of data.
--- ping statistics ---
7 packets transmitted, 0 received, 100% packet loss, time 6006ms

Rebooting the windows web server solves this issue temporarily with no other changes to the network but our experience shows this issue will come back.

Swapping network cards and switches

I noticed the link light on the port of the switch for the failed windows server was running at 100Mb instead of 1Gb on the failed interface. I moved the cable to several other open ports and the link indicated 100Mb for each port that I tried. I also swapped the cable with the same result. I tried changing the properties of the network card in windows and the server locked up and required a hard reset after clicking apply. This windows server has two physical network interfaces so I have swapped the cables and network settings on the two interfaces to see if the problem follows the interface. If the public interface goes down again we will know that it is not an issue with the network card.

(We also tried another switch we have on hand, no change)

Changing network hardware driver versions

We've had the same problem with the latest Broadcom driver, as well as the built-in driver that ships in Windows Server 2008 R2.

Replacing network cables

As a last ditch effort we remembered another change that occurred was the replacement of all of the patch cords between our servers / switch. We had purchased two sets, one green of lengths 1ft - 3ft for the private interfaces and another set of red cables for the public interfaces. We swapped out all of the public interface patch cables with a different brand and ran our servers without issue for a full week ... aaaaaand then the problem recurred.

Disable checksum offload, remove TProxy

We also tried disabling TCP/IP checksum offload in the driver, no change. We're now pulling out TProxy and moving to a more traditional x-forwarded-for network arrangement without any fancy IP address rewriting. We'll see if that helps.

Switch Virtualization providers

On the off chance this was related to Hyper-V in some way (we do host Linux VMs on it), we switched to VMWare Server. No change.

Switch host model

We've reached the end of our troubleshooting rope and are now formally involving Microsoft support. They recommended changing the host model:

We did that, and we also got some unpublished kernel hotfixes which were presumably rolled into 2008 R2 SP1. No fix.

Replacing network card hardware

Ultimately, replacing the Broadcom network hardware with Intel network hardware fixed this issue for us. So I am inclined to think that the Broadcom Windows Server 2008 R2 drivers are at fault!


Source: (StackOverflow)

How do I disable TLS 1.0 without breaking RDP?

Our credit card processor recently notified us that as of June 30, 2016 we will need to disable TLS 1.0 to remain PCI compliant. I tried to be proactive by disabling TLS 1.0 on our Windows Server 2008 R2 machine, only to find that immediately after reboot I was completely unable to connect to it via Remote Desktop Protocol (RDP). After some research, it appears that RDP only supports TLS 1.0 (see here or here), or at least it's not clear how to enable RDP over TLS 1.1 or TLS 1.2. Does anybody know a way to disable TLS 1.0 on Windows Server 2008 R2 without breaking RDP? Does Microsoft plan support for RDP over TLS 1.1 or TLS 1.2?

Note: There appears to be a way to do it by configuring the server to use the RDP Security Layer but that disables Network Level Authentication, which seems like trading one evil for another.

UPDATE 1: Microsoft has now addressed this issue. See the answer below for the relevant server update.

UPDATE 2: Microsoft has released a tutorial regarding SQL Server Support for PCI DSS 3.1.

Source: (StackOverflow)

What's the meaning of logging in as "username@mydomain.com:something"

My Windows 2008 R2 machine is joined to a domain.

In the logon screen, if I type in "username@mydomain.com:something" as the username, I can still logon properly, what's the meaning of ":something" appended at the end?

I can even see the current user is displayed as "username@mydomain.com:something" in the switch user screen. Is it a feature in Windows? Or is it just a bug? If it is a feature, what's the difference between logging in as "username@mydomain.com" and logging in as "username@mydomain.com:something"?

Note that I tried different combinations like "mydomain\username:something" and "mydomain.com:something\username". None of them work except "username@mydomain.com:something".

Sept 10 2012 Update

RunAs problem raised by Justin is similar but not exactly the same as the problem that I want to solve. If you do

runas /user:username@mydomain.com:anything

you will get

RUNAS ERROR: Unable to acquire user password

I verified that RunAs doesn't even bother to call into LSA when seeing username@mydomain.com:anything as the username. RunAs should have done input validation and return error there.

WinLogon is different. It accepts this format of input and pass the "username@mydomain.com:anything" into LSA. I do see the LogonUserEx2 inside kerberos.dll got called. It's either there is a bug in WinLogon input validation logic or this is really an acceptable format for some hidden features.

Sept 26 2012 Update

I just submitted a case to Microsoft Premier Support. I will update here if I get any update from them.

Source: (StackOverflow)

How can I connect to a Windows server using a Command Line Interface? (CLI)

Especially with the option to install Server Core in Server 2008 and above, connecting to Windows servers over a CLI is increasingly useful ability, if not one that's very widespread amongst Windows administrators.

Practically every Windows GUI management tool has an option to connect to a remote computer, but there is no such option present in the built-in Windows CLI (cmd.exe), which gives the initial impression that this might not be possible.

Is it possible to remotely management or administer a Windows Server using a CLI? And if so, what options are there to achieve this?

Source: (StackOverflow)