Having worked with Intel Active Management Technology and Intel vPro Technology since version 1.0, it seems to me that there are a whole host of possibilities for those who are do-it-yourself-ers. One is the ability to programmatically wake a system, remotely trigger a process such as a software patch, and then put the system back to sleep. As it turns out, this is not so hard, even for me who has a limited scripting (read batch file) capability. The video chronicles the results of my effort.

Disclaimer: this is not meant as a how-to or best method. Rather, it is an exploration of what’s possible, meant to educate and stimulate conversation. With that out of the way, let’s get to the fun stuff.

To accomplish this goal I knew I'd need some help via command line tools. I did an Internet search and found these 4 freely downloadable tools that made it all possible. They are;

Remote Control Util - to determine the current power state and turn the system on.

PsService - to start a process remotely

PsShutdown - to put the system back to sleep

sleep.exe - so the batch file can sleep while an event takes place.

The setup is simple; 2 systems. One is the console that executes the batch file and these commands. The other is my vPro system. I setup and configured my it using this Use Case Reference design (another of my batch file creations). That is to say, there's no TLS and I'm using only the admin account. I then ran the batch file on the console system which triggered the whole process. The process is as follows:

1.     Remote control util gets vPro's original power state via AMT (on, sleep, hibernate, or off)

2.     Remote control util power's on vPro via AMT

3.     Remote control util get's vPro's new power state to verify it has turned on

4.     ping vpro and check the TTL. Once it changes to <=128 the OS has booted. For more info

5.     PsService starts a process on vPro. I used notepad but it could be anything, including triggering a download and run of software patch

6.     PsService exits when the process finishes

7.     PsShutdown gracefully places vPro back to it's original sleep state

8.     Remote control util get's vPro's new power state to verify it has returned to it's original power state

Couple of notes.

·         I set an auto login on my vPro so I could see the process. However, PsService will work without a user being logged in. Also, it can run processes in the back ground so an end user would not be able to interact.

·         I used Notepad as my remote process since it made it easy to see success. However, any process can be started. In fact, PsService supports downloading the executable to run. As such, it may be possible to download and then run a patch or batch file as part of this whole process

·         I used a single vPro system. But, with a simple loop the same core batch file could trigger this action on many vPro systems.

Hope you found this post enjoyable and thought provoking. If you have your own do-it-yourself vPro ideas, or want to recreate this one, please share. And, hey, who says batch files are dead?

At TechEd Europe 2009, Microsoft's Keith Mayer outlines how manageability can be achieved with Windows 7, Windows Server 2008 R2 and Intel's Westmere-EP.     

This issue of the newsletter has some good content about using Intel vPro Technology. A new use case reference design was published recently; this one has to do with using Radmin to perform basic Intel AMT functions on a managed client. (What's a use case reference design? Read my blog: New stuff in the community: Use Case Reference Designs) You'll also find links to a white paper about Failsafe and Intel Anti-Theft Technology, a registration link for a Windows 7 webinar that's coming up, and some real-world stories about companies that have implemented Intel vPro technology in their environments.

Read the newsletter or subscribe to receive it in your inbox automatically. This newsletter goes out every two weeks.

Enjoy!

Sharing an experience and looking to validate some of the challenges vPro demonstration might present in markets outside of North America - especially if the original demonstration environment was created in North America.

A few weeks ago I had the opportunity to travel to Germany for a training event.   The equipment for the training event was sourced locally in Germany.   The result was 13 systems.  (For those that are superstitious – you might quickly identify that this will get interesting).  

Among those 13 systems, there were 4 different OEMs, 3 different keyboard layouts (US, UK, German), 3 different power connectors, 2 generations of Intel AMT (2.6 and 4.x), 3 different versions of Windows (XP, Vista, and Win7), 2 different versions of VMware workstation, and a single VMware workstation image created in North America.   Very little standardization.   A perfect recipe for disaster.

This was my first experience in working with differences that went beyond just QWERTY vs. QWERTZ keyboards.   The password used for the operating system and applications included the @ key.   This was problematic since on a US-based keyboard the location of '@' is Shift-2, yet a German keyboard is AltGr-Q  (press and hold key to right of spacebar, then press Q), and a UK-keyboard is Shift-‘ (press and hold shift, then press ‘ key which is located on third row third key from the right side).   Fortunately I didn’t have to deal with keyboards outside of Latin letters (i.e. A, B, C, etc) – although there are exceptions like the German letter β.

My first realization of internationalization troubles was that BIOS\MEBx screens and key sequences were US-keyboard QWERTY based regardless of the keyboard layout.   I had to ask myself - "Is this always true?".   Since the password included the @ symbol - mentally I had to follow the US-keyboard layout, althought the sequence wouldn't match the printed keys on the system.

When in the host operating system, the “Regional and Language settings” were commonly set to the origin of that system (expect one system which had UK keyboard with US-based Windows Regional and Language settings).   My frustration did not end there – as the VMware environment was set to US-based Regional and Language settings, and had to be adjusted on a per-system configuration basis.

Not all of the windows menus and options were in the same locations between English and German, yet there were similarities.   With the differences of languages between BIOS\MEBx, host windows operating system (with VMware workstation), and demonstration environment – some real-time translation or best guess had to be done.  I know some German, thus I was able to navigate through menus in the host operating system or VMware application, yet it slowed setup and troubleshooting situations.   Fortunately those attending the training knew English better than my German language skills... but frustrating nonetheless.

The good news – the underlying vPro functionality was the same, the training was delivered, and a new perspective was obtained by myself and those who received the training.

In talking with my international associates, a few more points were brought to my attention:

• difference of calendars (for example, those that use Buddhist calendaring system) which may affect Kerberos and certificates
• application installations may fail when using a foreign language
• Remote configuration certificate is issued to one domain (i.e. domain.company.com) yet will not support international domains (i.e. intldomain.company.com.uk)... this one is actually fixed in the latest firmware and will be explained in a separate article

There are likley other subtleties to the challenges of internationalization

Does this all sound familiar to those outside of the US?  

The experience was good for me.   I gained a brief look into much larger challenges on standardizing a technology solution across the globe.  

In today’s environment, the pressure to justify any investment is high and often, delaying your PC refresh cycle seems like an easy answer.   Join me tomorrow for a webinar with Dave Bowers from Dell for a discussion on the financial reasons to renew, redeploy and refresh an aging PC fleet.   We’ll cover key areas to consider that can impact the total cost of ownership for your PC fleet – such as energy savings, security, and productivity.  We’ll also provide you with access to tools that you can use to develop your own analysis and assist you in your budgeting conversations for next year.  Learn more about optimizing your PC refresh cycle and reducing your total costs.

Register here and ask your finance colleague to join you!

Thewebsiteisdown.com gives us a new installment.  While I agree this is possible from the admin standpoint, I don't encourage you to try it at this scale.

Here's a compilation of some of the issues that were added in the last few months to the Known Issues, Best Practices, and Workarounds wiki:

• LANDesk* 8.8 SP2 console requires repeated deletion of two directories when provisioning
• Failure of collection-based power control in Microsoft* SCCM SP1
• Intel^® MEBX, Web UI, and remote admin passwords are not automatically synchronized
• Tips on ME firmware updates
• Wrong IP address for Intel ME on Lenovo M58p using Hypervisor
• Intel(R) AMT does not allow multiple simultaneous commands
• Need to set LANDesk* root certificate as trusted certificate
• Intel(R) SCS is only supported on English versions of Windows* Server 2008
• Usage of Locally Administered Address on Intel^® Active Management Technology enabled systems

Take a look at a recently posted document providing insights on what might cause a rapidly expanding database, key learnings how to minimize the growth and provide good performance, and more.

http://communities.intel.com/docs/DOC-4306

The document may be updated over time, depending on requests, inputs, and so forth