windows 2008R2 server - unable to connect to internet

IP addresses are still registered on the DNS servers even if the IP addresses are not used for outgoing traffic on a computer that is running Windows 7 or Windows Server 2008 R2 

 

 

SYMPTOMS

Consider the following scenario:

• You assign many IP addresses to one network adapter of a computer that is running Windows 7 or Windows Server 2008 R2 in a domain.
• You use only the primary IP address for outgoing traffic.

In this scenario, all IP addresses are registered on the DNS servers. Additionally, a large amount of unnecessary DNS registration and update traffic is generated.

If you configure a firewall to allow traffic for only the primary IP address, traffic to the computer may be blocked by the firewall. For example, the traffic may be blocked by the firewall if all the assigned IP addresses are registered on the DNS servers and if the traffic uses the non-primary IP addresses.

CAUSE

This issue occurs by design. Additionally, there is no option to change this default behavior. Therefore, all assigned IP addresses are registered on the DNS servers of the domain.

RESOLUTION

After you install this hotfix, you can assign IP addresses that will not be registered for outgoing traffic on the DNS servers by using a new flag of the netsh command. This new flag is the skipassource flag.

Note You can create IP version 4 (IPv4) addresses and IP version 6 (IPv6) addresses by using the netsh command together with the new skipassource flag.

For example, the following command creates an IPv4 address that is not registered for outgoing traffic on the DNS servers:

Netsh int ipv4 add address <Interface Name> <ip address> skipassource=true

Notes

• "Interface Name" is the name of the interface for which you want to add a new IP address.
• "Ip address" is the IP address you want to add to this interface.

To list the IPv4 addresses that have the skipassource flag set to true, run the following command:

Netsh int ipv4 show ipaddresses level=verbose

 
steps 


1)     

1)      Backup, “ipconfig /all” details.

2)      Backup, Route Table Entries.

3)      Open iLO, VMWare Console, Login to the server.

4)      Reset IP Configuration  – “netsh int ip reset”

5)      Reset Network Adapter  – “netsh winsock reset”

6)      Add primary IP address on NIC.

7)      Add secondary IP’s one after the another,

“netsh int ipv4 add address <Interface Name> <ip address> <subnetmask> skipassource=true”

Example

“netsh int ipv4 add address frontend 192.168.0.2 255.255.252.0 skipassource=true”

 

Example

“netsh
int ipv4 add address frontend 192.168.0.2 skipassource=true”



8)     
To
confirm, the secondary IP’s assigned through “skipassource”
“netsh int ipv4 show ipaddresses level=verbose”

Source: 


 https://support.microsoft.com/en-us/kb/2386184
 

Hotfix Download Available

windbg in detail

http://windbg.info/doc/1-common-cmds.html

Threads and handles explained

When you start a program, that program runs as a 'process'. This is something that runs in its own protected area, with its own memory. Other processes can't touch that memory.

Some times the program needs to do several things at once in a multitasking way, similar to the way the processes multitask. For example, a spreadsheet might recalculate cells as you are entering data. It *could* start another process, but they can't (easily) share memory, which it would need to if recalculating cells! 

So we need another sort of process that isn't quite so separated. This is a 'thread'. Threads live within processes, and share the same memory as other threads within that process.

When a program opens a file, or wants to talk to the Internet it asks Windows to do this, and tells Windows what file etc is required. Windows does this, and hands back a token to the program to use in subsequent operations so that Windows can keep track of what is done. This token is called a 'handle' and basicaly is a (fairly) random 32bit number.

Clearly Windows has to keep track of handles, processes and threads - they all take resources. So that part of the info-panel tells you just how many of these are in use.

Source : A techie (harry) explained in http://www.certforums.com/

Unable to RDP 2008 R2 sp1 - This computer can't connect to remote computer

We have received the below mentioned error message while connecting the 2008 R2 SP1 server thru RDP


####





We have installed the MS recommended patch to overcome this issue and this didn't really helped in our scenario.


Resolution :

We have changed Remote desktop security settings and issue has been resolved

















Note : RDP security layer with Low encryption level is not recommended .

#################################

https://technet.microsoft.com/en-us/magazine/ff458357.aspx

Secure RDS (Remote Desktop Services) Connections with SSL

Follow Our Daily Tips

Twitter | Blog | RSS | Facebook

By default, RD Session Host sessions use native RDP encryption. However, RDP does not provide authentication to verify the identity of an RD Session Host server. You can enhance the security of RD Session Host sessions by using Secure Sockets Layer (SSL) Transport Layer Security (TLS 1.0) for server authentication and to encrypt RD Session Host communications. The RD Session Host server and the client computer must be correctly configured for TLS to provide enhanced security.

The three available security layers are:

• SSL (TLS 1.0) SSL (TLS 1.0) will be used for server authentication and for encrypting all data transferred between the server and the client.
• Negotiate The most secure layer that is supported by the client will be used. If supported, SSL (TLS 1.0) will be used. If the client does not support SSL (TLS 1.0), the RDP Security Layer will be used. This is the default setting.
• RDP Security Layer Communication between the server and the client will use native RDP encryption. If you select RDP Security Layer, you cannot use Network Level Authentication.

A certificate is needed to authenticate an RD Session Host server when SSL (TLS 1.0) is used to secure communication between a client and an RD Session Host server during RDP connections. You can select a certificate that you have already installed on the RD Session Host server, or you can use the default self-signed certificate. You can enable SSL for Remote Desktop connections using the RDP-Tcp Properties dialog box, which is accessed from the Remote Desktop Session Host Configuration snap-in.

For Remote Desktop connections, data encryption protects data by encrypting it on the communications link between the client and the server. Encryption protects against the risk of interception of the client/server communication.

By default, Remote Desktop connections are encrypted at the highest level of security available (128-bit). However, some older versions of the Remote Desktop Connection client application do not support this high level of encryption. If a high level of encryption is needed to support legacy clients, the encryption level of the connection can be configured to send and receive data at the highest encryption level supported by the client. There are four levels of encryption available:

• Low Data sent from the client to the server is encrypted using 56-bit encryption. Data sent from the server to the client is not encrypted.
• Client Compatible Encrypts client/server communication at the maximum key strength supported by the client. Use this level when the terminal server is running in an environment containing mixed or legacy clients. This is the default encryption level.
• High Encrypts client/server communication using 128-bit encryption. Use this level when the clients accessing the terminal server also support 128-bit encryption. When encryption is set at this level, clients that do not support this level of encryption will not be able to connect.
• FIPS Compliant All client/server communication is encrypted and decrypted with the Federal Information Processing Standards (FIPS) encryption algorithms. FIPS 140-1 (1994) and its successor, FIPS 140-2 (2001), describe U.S. government requirements for encryption.

The RDP-Tcp Properties dialog box, which is accessed from the Remote Desktop Session Host Configuration snap-in, allows you to configure the encryption level.

RD Session Host authentication and encryption settings can also be configured by applying the following Group Policy settings:

• Set Client Connection Encryption Level
• equire Use Of Specific Security Layer For Remote (RDP) Connections
• Server Authentication Certificate Template
• Require User Authentication For Remote Connections By Using Network Level Authentication

These Group Policy settings are located in the following container:
Computer Configuration\Policies\Administrative Templates\Windows Components\Remote Desktop Services\Remote Desktop Session Host\Security

FIPS can be specified as the encryption level by applying the System Cryptography: Use FIPS Compliant Algorithms For Encryption, Hashing And Signing Group Policy setting located in the following container:
Computer Configuration\Policies\Windows Settings\Security Settings\Local Policies\Security Options

From the Microsoft Press book Understanding Microsoft Virtualization Solutions, Second Edition by Mitch Tulloch with the Microsoft Virtualization Teams.