With Intel vPro Technology allowing for improved remote management via reliable power-on, boot redirection, and so forth - using the technology in a day-to-day environment might reveal some unexpected behaviors.
The unexpected behaviors are not necessarily the technology, but how the technology is used.
Outside of Intel vPro technology, how responsive is an IT infrastructure during the morning hours? Consider that workers are powering on systems, logging in, getting email downloads, opening intranet sites\applications, etc. From an IT infrastructure perspective, there will be noticeable uptake on system\infrastructure resources as logon requests are processed, web pages are served up, etc. It's like the morning commute where you and a few thousand others are trying to get onto the highway... (and for those out there that enjoy working from home, you're not isolated. The IT infrastructure still has to handle the VPN connectivity, email downloads, etc, etc)
Well - Intel vPro technology is sometimes blamed for unexpected traffic or application responsiveness issues. For example, a collection of systems are scheduled to power-on at 3am for patching\maintenance. Intel vPro technology will help in powering on the target collection of systems - be it a few hundred or a few thousand. The nature of the Intel vPro technology communications is unicast, and there is an authentication with possible encryption process that has to happen. If Kerberos authentication is needed, that means that the management server is utilize Microsoft Active Directory Kerberos authentication to login to the Intel vPro technology of the target systems, followed by sending the desired commands. That whole communication cycle might be a few 100kb of data on the network - relatively minimal. But - when that 100kb is replicated a few hundred or thousands times for a per instance between management server and target client systems, the traffic will be higher on the network and applications queues.
Let's play out this scenario one step further. A collection of systems (again few hundred or few thousand depending on your collection size\structure) are powering on with agents\services starting up, and some of those agents are attempting to authentication and communicate on the network. It may be network authentication due to endpoint access control (i.e. 802.1x, NAC, NAP, etc). It may be a check-in and update sequence with an internal patching, security definition update server (i.e. McAfee), and so forth. What might be a viewed as a flood of traffic on the network should not be targeted as the fault of Intel vPro technology... but in how the technology was utilized, and how available the infrastructure was to handle the flood of requests.
Similarly, using Intel vPro technology to power-off a collection of systems would be equivalent to pressing\holding the power button on all of the systems to force a hard shutoff. The power-on or power-off sequence via Intel vPro technology directly changes the power state from S0 (system on) to S5 (system off). For some applications or services this might cause corruption of file cache, logs, data, and so forth. A better approach would be to utilize a graceful power-off for a healthy operating system environment. This can be done via WMI call, management agent, windows script with command like "shutdown -s -f -t 5", and so forth. Intel vPro technology is talking directly to the hardware, is operating system agnostic, and was meant to be utilized in scenarios where the host operating system was unavailable or inoperable.
