Pages

4/22/2011

DHCP Client Behavior - Microsoft Enterprise Networking Team - Site Home - TechNet Blogs

DHCP Client Behavior - Microsoft Enterprise Networking Team - Site Home - TechNet Blogs: "To disable APIPA, set the following registry key:

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters\Interfaces\adapter_name (for the specific adapter)

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\Tcpip\Parameters (for all adapters)

IPAutoconfigurationEnabled: REG_DWORD

0 – APIPA disabled

1 – default"

When a DHCP server is unavailable on a Windows Vista-based computer, Windows Vista uses an APIPA IP address much sooner than Windows XP does under the same circumstances

When a DHCP server is unavailable on a Windows Vista-based computer, Windows Vista uses an APIPA IP address much sooner than Windows XP does under the same circumstances: "This behavior occurs if Windows Vista cannot immediately contact a DHCP server. In this situation, Windows Vista tries for only six seconds to contact a DHCP server and then uses an APIPA IP address. Then, Windows Vista continues trying to acquire an IP address from a DHCP server."

DHCP Client Behavior - Microsoft Enterprise Networking Team - Site Home - TechNet Blogs

DHCP Client Behavior - Microsoft Enterprise Networking Team - Site Home - TechNet Blogs: "A registry key to control this is: AutonetRetries which may be placed as a DWORD in:

HKLM\SYSTEM\CurrentControlSet\Services\Dhcp\Parameters

OR

HKLM\SYSTEM\CurrentControlSet\Services\tcpip\Parameters

AutonetRetries controls the: 'DEBUG_LEASE [0]0430.0910::10/14/2008-20:59:41.244 (ReObtainInitialParameters:protocol_c3191)Sleeping for 275 seconds' time period

Thus if the registry is set to 30 (decimal) for example, then the sleep time is reduced to 30 seconds. This means that the set of 4 tries will be sent out every 30 seconds.

Also another interesting reference is:

KB 928233 – Windows Vista cannot obtain an IP address from certain routers or from certain non-Microsoft DHCP servers

Another registry key suggested here is DhcpConnEnableBcastFlagToggle

Though the purpose of this registry is completely different, on closer inspection, this setting has a side effect in Windows Vista where it sends out 2 sets of DISCOVER packet sets like Windows XP, albeit one set with and the second set without the Broadcast flag. Subsequent sets will be controlled by the AutonetRetries setting (300 seconds by default)."

DHCP Client Behavior - Microsoft Enterprise Networking Team - Site Home - TechNet Blogs

DHCP Client Behavior - Microsoft Enterprise Networking Team - Site Home - TechNet Blogs: "Thus, if we consider the first DISCOVER packet at 0 seconds, then 4 packets are sent out as:
0th second - 1st packet with 5 sec timeout
5th second - 2nd packet with 7 sec timeout
12th sec: 3rd packet with 15 sec timeout
27th sec: 4th packet with 32 sec timeout

The above 4 packets with a final timeout of about 1 minute may be considered as a “set” for the purpose of this discussion.

In Windows Vista: One such set is sent out every 5 minutes as can be seen above. After one set, the DHCP client sleeps for 275 seconds or over 4.5 minutes."

TRACE:
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:42.943 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:42.943 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:42.943 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 5 seconds
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:42.943 (TryReceive:dhcpmsg_c471)Select: waiting for: 5 seconds

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:47.304 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:47.304 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:47.304 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:47.304 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 7 seconds
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:47.304 (TryReceive:dhcpmsg_c471)Select: waiting for: 7 seconds

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:54.184 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:54.184 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:58:54.184 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:54.184 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 15 seconds
DEBUG_TRACE [0]0430.0910::10/14/2008-20:58:54.184 (TryReceive:dhcpmsg_c471)Select: waiting for: 15 seconds

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:09.815 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [1]0430.0910::10/14/2008-20:59:09.815 (SendDhcpMessage:dhcpmsg_c268)Sent message to 255.255.255.255:
DEBUG_PROTOCOL [1]0430.0910::10/14/2008-20:59:09.815 (ObtainInitialParameters:protocol_c2204)Sent DhcpDiscover Message.
DEBUG_TRACE [1]0430.0910::10/14/2008-20:59:09.815 (ObtainInitialParameters:protocol_c2212)Waiting for Offer: 32 seconds
DEBUG_TRACE [1]0430.0910::10/14/2008-20:59:09.815 (TryReceive:dhcpmsg_c471)Select: waiting for: 32 seconds

EBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (ObtainInitialParameters:protocol_c2222)Dhcp offer receive Timeout.

DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (ObtainInitialParameters:protocol_c2510)121(ERROR_SEM_TIMEOUT)
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (DhcpSetRcvAllMode:protocol_c3941)RcvAll: 0
DEBUG_PROTOCOL [0]0430.0910::10/14/2008-20:59:41.243 (ReObtainInitialParameters:protocol_c3111)Autoconfiguring....
DEBUG_TRACE [0]0430.0910::10/14/2008-20:59:41.243 (ReObtainInitialParameters:protocol_c3153)Ready to acquire autonet address. Notifying NLA...

DEBUG_LEASE [0]0430.0910::10/14/2008-20:59:41.244 (ReObtainInitialParameters:protocol_c3191)Sleeping for 275 seconds.

DHCP Client Behavior

DHCP Client Behavior - Microsoft Enterprise Networking Team - Site Home - TechNet Blogs
in situations where a DHCP Server fails or is not available, client behavior needs to be understood for efficient use. Then there are cases where a laptop user roams between his house (static IP) and office (DHCP) and does not want to keep changing the TCPIP properties every time.

First, let’s understand DHCP client behavior when DHCP server is not available. To understand well, we will observe the etl trace taken on a DHCP client. Ref: http://technet.microsoft.com/en-us/library/cc731630.aspx - “netsh dhcp client trace enable”. Etl tracing is saved as the following files: %windir%\system32\logfiles\WMI\dhcpcsvc.etl, dhcpcsvc6.etl and dhcpqec.etl.

4/18/2011

OpsMgr/SCOM 2007 R2 Implementation and Administration Best Practices – Toolzz.com

OpsMgr/SCOM 2007 R2 Implementation and Administration Best Practices – Toolzz.com OpsMgr/SCOM 2007 R2 Implementation and Administration Best Practices General Always run 64 bits hardware, OS and 64bits SQL Be sure to have enough bandwidth for core OpsMgr components and agents. Virtualization is supported on all OpsMgr roles but don’t cluster the Root Management server virtual. Snapshot backup is not supported for disaster recovery Operational Database Limit the number of consoles sessions to less than 50 Configure the SQL OpsMgrDB to use simple recovery unless you plan to use log shipping Be sure to have quick disks because of extensive I/O usage When using multi clustering be sure the connection is very fast because of disk latency Database grooming, don’t increase the default 7 days RMS (Root Management server) Never connect agents directly to the Root Management Server Never connect gateway servers directly to the Root Management Server The Root Management Server is most critical in RAM followed by CPU Limit console connections and SDK clients (webconsole, third party tools) Do not run the console on the RMS Never put the RMS in Maintenance Mode Management server Management servers talks to Root Management Servers but writes directly to OpsMgrDB Keep them close to the Root Management Server, OpsMgrDb, OpsMgrDW because of latency Memory and CPU Gateway Server (remote office) Data compression by almost 50% Dedicated management server for all gateways when using a large number of agents (R2 will support 1500) Console Use Clear the console cache /clearcache only when you have console issues Reporting Datawarehouse Limit the number of users who can generate reports Separate the SQL Data files from the transaction logs onto different disk array’s Get a DR plan Be sure you have a Disaster Recovery plan with DB and encryption key backup and test this.

System Center Operations Manager 2007 Tools & Utilities

System Center Operations Manager 2007 Tools & Utilities Important Link

4/07/2011

Dealing with WMI Timeouts « Use PowerShell

Dealing with WMI Timeouts « Use PowerShell: "The timeout value is a System.TimeSpan object. You can specify the value with a TimeSpan object, a number of ticks, or a string that can be cast to a TimeSpan.

It can be set like this:

$wmi = [wmi]”

$wmi.psbase.options.timeout =’0:0:2′ #String that will be cast to a two second TimeSpan"