Yes this is about IPtel, and yes it is a deployment issue. It is about knowing what is being deployed and the configuration options/settings.
I was recently tasked to investigate an interesting issue with a customers Windows Vista/7 deployment. Here’s the approach I use, and the outcome – not really what I was expecting, but it fixed the issue.
Subjective: What is the user experience/perception?
User1: “Sometimes when I am on a telephone call, the call just drops.”
User2: “My Live Meeting sessions are ok, but then they suddenly disconnect.”
These comments don’t really fill one with confidence in a flexible IT environment. So I had a few users demonstrate it to me. Sure enough, the call would drop, but all the users neglected to describe the situation fully:
1. They were indeed on a call or live meeting. These are time-critical applications – so any service interruption is noticeable.
2. LiveMeetings only dropped when the user was not paying attention (using the mouse). Ahem!
3. The dropout occurred just after the monitor went blank.
Objective: What is the empirical assessment?
Turns out the observations aligned well with the system configuration. The dropouts only occurred when the monitor went blank – directly related to the following setting in the customer’s power plan – after 5 minutes of inactivity, the screen blanks and the link dropped shortly thereafter.
So the big question was - Why does a telephone call dropout when the monitor goes blank? A bit more research yielded an interesting technology.
Assessment: What is likely to be a cause?
Intel developed a software-based technology known as System Idle Power Saver (SIPS). It is available on selected mobile gigabit network cards, if the operating system supports the capability. Typically this is Windows Vista and later. SIPS is triggered when the monitor goes blank (via an NDIS notification) indicating inactivity of the system. SIPS then attempts to negotiate down the link speed of the systems NIC to save power. The negotiation will occur to the minimum supported by the PHY and the link partner.
Link speed negotiation can take some time…up to 60 seconds depending on how the networking infrastructure is configured. So impact to a near-real-time system like telephony is significant with a 60 second delay.
Plan: What can be done about it?
SIPS is available in the Advanced tab of the network card device properties. It can be either enabled or disabled on a per-device basis. Some manufacturers have shipped NIC drivers with SIPS enabled. So the options to fix this are:
1. Change them manually. Who does this these days?
2. Work out how to programmatically disable SIPs – yes there is a way!
There is a tool provided by Intel that is packaged by HP here. This can be used in a task sequence to programmatically assess and disable (or enable) SIPS. i typically drop this into %SCRIPTROOT%\HWTools, and invoke it using:
1. Device Drivers: Know the feature set of the drivers being deployed in the environment. Some manufacturers are now shipping NIC drivers with SIPS disabled by default.
2. Device Drivers: It is tempting to modify the INF files to disable features that aren’t required. While this achieves the desired outcome, it is likely to invalidate the driver signature.
3. Device Drivers: Contact the device vendor for an updated driver set if particular features need to be disabled. As the 64-bit platform becomes ubiquitous, driver signing becomes an imperative. So try not to invalidate drivers signatures.
4. Power Plans: Modifications of the power plan must be tested, and the impact of changes fully understood.
5. Image Creation/Deployment: Execute the SIPS tool as part of the task sequence in MDT or Configuration Manager to disable SIPS. If no supported driver is present, then no changes are made to the registry (according to the supporting documentation for the tool). The tool also provides return codes that can be used for logic operations within the task sequence.
This post was contributed by Samesh Singh, a Principal Consultant with Microsoft Services Australia