Information on using vPro technology to troubleshoot systems and deploy operating systems

[idata]

Hi,

So far I've provisioned about 300 Dell 755s with vPro technology and all new PCs will be vPro enabled. I've played around with the redirect function and I'm very impressed with the technology but I admit to being a little confused. The case studies and docs mention that now you can use the redirect function to cause a remote PC to boot into another operating system and then perform maintenance and troubleshooting on that PCs OS (replace corrupt files, run virus scan etc). Since the redirection terminal console stops displaying text data once the system boots into it's guest OS (other than a simple DOS boot), how do you actually "use" this operating system? Do you need to remote control the machine using the guest OS or do you have to automate these maintenance functions to the point where they run unattended after the guest OS boots? ...Or am I completely out in left field on this? Any advice would be appreciated.

Also, if anyone has any detailed information on how to use vPro to remotely reimage a Windows PC...please pass that along as well.

Thanks much

[Terry_C_Intel]

Interested to know - how long did it take you to get the first 300 system provisioned? How many more are planned in the near term, and what key learning (or resources) are in place to improve the process? What is yet needed - in your view?

Now to your question -

IDE-Redirection enables the specification of a different boot device with the ability to override the BIOS boot order settings. Common options include specifying a local Intel vPro client boot (harddrive or optical drive), remote client boot from management console harddrive or optical drive, bootable CD-ROM image (e.g. ISO)or floppy image (e.g. IMG) from a defined UNC path to which the administrator\user has read rights to, or forcing a PXE boot (which requires supporting infrastructure).

A brief video example is available at http://www.youtube.com/watch?v=KkJlp7pCACs

IDE-Redirection (IDER) and Serial-over-LAN (SoL) are not directly connected. You could initiate either without the other.

SoL (redirecting of the keyboard and video) works in ANSI or VT-100 mode. Once you enter a GUI mode - the session is no longer accessible.

Another point to consider - Intel vPro is enabling technology to extend the reach of existing client management solutions. Therefore, it was not intended to enable aall the functionality\process for reimaging a remote PC. However, it will reliable boot a remote system, redirect or override the default boot order using a local or remote boot image, etc.

Some ideas:

• Text based diagnostic utilities using IDER and SoL

• Bootable ISO or CD-ROM from management console with WinPE or BartPE

• Bootable ISO or IMG to initialize the target system, load network, utilize a disk imaging utility to pull down an image

There are likely other uses and ideas out there...

[Matthew_R_Intel]

Although Serial Over LAN (SOL) and IDE Redirect (IDER) are frequently used together, it is important to keep in mind that they are two separate vPro capabilities. IDER can work independently from SOL as long as no direct interaction is required. Similarly, SOL can allow you to interface with the client's pre-boot environment and BIOS without the use of IDER. As you have noted, the SOL feature is restricted to terminal character displays only; once a graphical user interface is presented, you lose the ability to visually interact with it through the SOL terminal session.

The option you mentioned around crafting a fully automated and unattended boot images (Terminal or Graphical) works well for task orientated use cases. Scenarios such as out of host OS virus scans, hard drive reimaging, known task repairs (i.e. resolving static corruption caused by some wide spread malware), etc can be played out in an unattended fashion. If necessary, you could enable enough of a network stack within the unattended guest OS to send report outs of progress / status to a centralized locations or interface with the Manageability ISV (depending on the ISV's capability) for additional instructions or steps. This type of process works well for broad based task or scenarios where you don't want / need to interact with the session.

In the cases where you need to "troubleshoot" what is going on, the visual interaction plays a more important role and that is where SOL comes into play. Based on the restrictions of SOL, we are currently limited to using terminal / character based Operating Systems. Although at first glance you may see that as a big limitation, there are numerous tools for MS/PC DOS and Linux distributions that will allow you to perform diagnostics, troubleshooting, and maintenance. I personally use one that was built off Ubuntu that allows me to perform a variety of task ranging from mounting local partition (NTFS, FAT, ext, etc), mounting remote shares, general hardware dialogistic tools, etc. A somewhat simple example of how this may be used is to perform a SOL/IDER session on a vPro Client that has a corrupted OS. Once the guest OS is booted, mount the local disk, find & copy user data files to a remote share, and re-image the partition with the standard corporate image.

In those scenarios where a terminal interface for the guest OS just will not do, you can always use the IDER to boot the Guest OS and then connect using VNC or something equivalent to connect to the GUI remotely over the network. In the MS Windows world, you could use Windows PE and then connect remotely via Remote Desktop; for Linux, start your x session and use VNC.

The examples above predominately focus on using a Guest OS to boot off of. In those cases where you want to see what is exactly happening on the Host OS, SOL will typically not work since most Host Operating Systems are running some form of Graphical Interface. If the host OS is up, you would still use the in band remote management tool (i.e. remote desktop, ISV agents) to establish connectivity and perform your troubleshooting. The challenge still remains when you want to interact directly with the Host OS and the Host OS network stack is inaccessible or the in band remote management tools are failing.

In terms of your question around using vPro to remotely reimage a Windows PC… There are a couple ways to do it depending on what tools you have available to you. One approach would be to create an IDER boot image that gets the vPro client on the network. From there you would boot the vPro client off the IDER image and either do a Windows unattended install over the network using an answer file or perform a partition restore using a product like Norton Ghost. Depending on the partition imaging product, they may already have a network boot disk that handles all the network stacks and remote re-imaging; technically all you should have to do there is point the IDER image to that boot disk.

[idata]

Thanks to Terry Cutler and login ID miroyer for their answers and explanations.

To answer Terry's question, it took me about a month to get those first 300 PC provisioned. There were problems with the firmware (reported a single duplicate UUID for all systems) and we had a strange bout with disconnects that seemed to occur during the initial "Hello" cycle. Dell released BIOS update A04 and it seems to have helped. I worked with Bill York from Intel to resolve all these issues. Bill is very knowledgible and facilitated the team work effort between Intel and Dell to resolve these issues. I also had to install an updated version of AMT for SMS 2003 because of a similiar UUID issue. To get the machines provisioned, I first ran an SMS job to get the BIOS up to A04. I used a list of successful upgrades along with the PSEXEC utility and and FOR command to remotely run the RCT tool. I found that running the RCT utility using the local system account via a SMS job fails - this is why I used the PSEXEC utility. Seems to working pretty good so far. We have potential of around 26K PCs in a total 10 domains but they are being phased in - thankfully. So far I think my little PSEXEC script should keep up. I forsee a constant stream of new PCs over the next couple of years.

Bill York also provided me with the educational resource. But Intel should rewrite the manuals - they seem disjointed and you have to do some serious digging.

I started working on a BartPE iso with VNC (would have rather used RDP) and going to load it up with a few choice tools. I figure I can use VNC and perform troubleshooting etc in that manner. I also plan to check out the "Ubuntu" tools that "miroyer" mentioned. Since we have several agencies to maintain, I'm going to look into WinPE automated install that would query a database to set configuration parameters and locate the nearest image based on IP subnet etc. I still have another 8 SCS servers to deploy as well because of the certificate to single domain issue but Bill tells me that may be corrected in a future release.

We will be upgraded to Microsoft's SCCM after sp1 is released. I'm hoping it will add a few more bells and whistles over SMS 2003's feature set.

Thanks again for the help and advice.