Home > Intel Communities > Open Port IT Community > Intel® vPro™ Expert Center > Blog > Authors > Terry Cutler
1 2 3 Previous Next

Intel vPro Expert Center Blog

40 Posts authored by: Terry Cutler
1

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.  

1 Comments Permalink
0

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

0 Comments Permalink
0

Earlier this year, Lenovo made a small change on their T400 and related platforms.   The Ctrl-P option disappeared when attempting to access the MEBx (Management Engine BIOS Extension screens for Intel Active Management Technology).   If you browse through the Lenovo BIOS update posting, there is a brief mention of this change.

 

The main reason was to improve boot times.   The difference is a few seconds.   All of the Intel AMT functionality is still present.

 

To access the MEBx screen, press F12 during the POST process to access the Boot Menu.

 

access-MEBx-T400.gif

The option "Enter ME Configuration Screens" will access the MEBx.

 

The option "Initiate a Remote Connection" is for the Client Initiated Remote Access (CIRA), more commonly referred to as "Fast Call for Help" - the ability for Intel AMT to make a call home for assistance.

0 Comments Permalink
1

In recent weeks, I've received a number of questions about Dell Client Manager 3.0 ability to configure Intel vPro technology.

 

I have not had the opportunity to review the latest official documentation from Symantec\Altiris or Dell on how to configure Intel vPro technology. 

 

Therefore, this blog provides my perspective and approach.  As I'm working with Altiris 7 and vPro on an almost daily basis, authoring a complete set of new documentation has not been accomodating to present schedules, tasks, etc.

 

 

I ask for your patience and understanding.   This is by no means the final and complete answer - it's a "best effort"

 

 

A few key points to keep in mind. 

So - you've started to deploy Intel vPro systems from Dell and are using their Dell client manager. 

 

Altiris 7 requires SCS 5.x to configure vPro.   If vPro is already configured - it's just a matter of enabling OOB Discovery and configuring the Pluggable Protocol Architecture (PPA).. see blip.tv video referenced above.

On the Dell Client Manager, check to see if the following fileshare exists – “\\localhost\nscap\bin\x86\Out of Band Management\IntelSCS”
If so – within that directory, find AMTconfserver.exe.   This is the Intel SCS service installation.   File should be version 5.0.2.4
On the Dell Client Manager, check for “c:\Altiris OOB Configuration” directory.  If present, you should see two files – Interop.AeXClient.dll and OOBProv.exe.
The preferred approach is to install Intel SCS via the Altiris (or Dell Client Manager) interface... but sometimes that scripted install fails without direct indication as to what happened.   Although a little advanced, it may be best to directly install the Intel SCS... which is the configuration service for Intel vPro technology.

Two key challenges I’ve seen in directly installing AMTconfserver.exe is that the webdirectories (AMTSCS and AMTSCS_RCFG) need to be set to no TLS and the the integration to SCS via the OOBprov.exe is not done.   The TLS settings are handled via the advanced installation options.   The OOBprov.exe is the configuration script which checks the Symantec\Altiris database against the IntelAMT database for new records, matching UUID\FQDN, recent vPro configuration events, and so forth.

As to what configuration script will be used, this setting is made in the IntelAMT database.   My preference is to use the SCS console to adjust the setting.   SCS console is available with the full download at http://software.intel.com/en-us/articles/download-the-latest-version-of-intel-amt-setup-and-configuration-service-scs/... The other good item here is the updated version of SCS 5.x  (presently SCS 5.2.0.34B)

So that's the brief summary. 

 

As stated previously - my intent was not to provide a complete answer, yet to provide a brief insight and references.

Interested to hear from the community.   Did this help?  More information needed?

1 Comments Permalink
2

During IDF2009, there were a few demonstrations on the upcoming embedded KVM (Keyboard, Video, Mouse) in the Intel vPro technology platform.

 

Here's a sneak peek of the technology.   One system shown - one screen is the embedded KVM, the other screen is a more than $150/port enterprise KVM solution.   Can you tell which is which?

 

 

 

More will be coming about the technology, how it works, how to configure, when it will be available, etc, etc.   For now - here is the teaser.

2 Comments Permalink
2

After working with Intel vPro technology for over 3 years - I still get surprised by little features that appear in the product.   Some features might not sound too interesting at first, but upon seeing how these are used my opinion changes.

 

One such features is the "PC Alarm Clock" capability in AMT 5, with software development support in the Intel AMT SDK 5.1.

 

An overview of this features is explained at http://communities.intel.com/docs/DOC-3483.... why that article is posted in the Server Room area of Open Port I do not know.

 

I was at IDF2009 this week and had a chance to visit the McAfee showcase booth.  What I saw was very impressive.   PC Alarm Clock provides a uniform "wake-up" at a defined time with an indication of what caused the power-on.   Was the system powered on because of a user hitting the power button or did the PC Alarm clock trigger the event?   Before visiting the McAfee booth, my first thought was "hey - that can be done via a system BIOS".   Well - I got some education.

 

Not all OEM BIOS setups support a timed wake-up.   If they do - having a uniform access to configure\control across OEMs would require disparate tools.   Plus - having a mechanism for an agent to know whether the system was powered due to user local to system or scheduled time is helpful.  Plus - an Intel AMT power-on event to a collection of systems is possible IF those systems are connected and IF you are okay with a unicast message to each system thus having a potential delay from first system to last system that powers on.  Plus - with PC Alarm Clock within Intel AMT - the time is synchronized.  Etc, etc

 

So here's the situation.   To avoid disrupting work hours with anti-virus scans or other maintenance routines... what if the system were scheduled to power-on at 3am to perform these tasks.   If powered on via PC Alarm clock, what McAfee agent will do is sense this and know that it's time to run a scan, and so forth.   At the conclusion of the scan, the McAfee setup will gracefully shutdown the system.   Thus - all assigned systems get a set time to power-on... and at that set time, all systems power-up, check to ensure it was a scheduled power-on, run the scan, and then return to an off start gracefully.

 

Ok - to some that might seem too simple to really matter.   But to me, after working with various management solutions and Intel vPro technology - that's a better cool approach.   It's a difference of push vs. pull... and when you're talking about hundreds or thousands of systems being orchestrated to perform an event... that little feature called "PC Alarm Clock" in the right hands such as McAfee... it's pretty cool

 

What do you think?

2 Comments Permalink
0

On Sept 2nd at 8am PDT, I'll be hosting a Symantec\vPro webinar. Register at -

 

 

 

https://www2.gotomeeting.com/register/947074427

The webinar is open to anyone.   It will provide insight to the Symantec\vPro compelling features and capabilities – emphasis will be on Endpoint Management, with references to BESR, pcAnywhere, SEP (anti-virus), and related Endpoint Management tools in connection with vPro.

The webinar content is a subset of the materials\discussions\demonstrations that occurred this week with the worldwide Symantec technical sales teams

To register for the webinar, please use the following link https://www2.gotomeeting.com/register/947074427

The webinar will be recorded and posted to the Intel vPro Expert Center.

Look forward to having you join

 

0 Comments Permalink
0

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.

0 Comments Permalink
0

Join us for a Webinar on June 11

Joint AMP Intel v2.jpg

Lower your IT manageability costs with Intel vPro and Altiris Client Management Suite

Join Advanced Marketplace and Intel as we discuss new approaches to common IT manageability challenges. This webinar will focus on how Intel vPro technology extends and enhances the Altiris Client Management Suite (CMS) with live demonstrations and discussions. The combination of Altiris CMS and Intel(r) vPro Technology will allow you to improve Power Management, SW distribution, Patch Management and help with Remote Diagnostics and Repair.  

Come ready to watch and learn the capabilities of these combined technologies and bring your questions to ask experts from Advanced Marketplace and Intel.

Title:

Lower your IT manageability costs with Intel(r) vPro and Altiris CMS

Date:

Thursday, June 11, 2009

Time:

10:00 AM - 11:00 AM PDT

Space is limited.
Reserve your Webinar seat now at:
https://www2.gotomeeting.com/register/300550755

After registering you will receive a confirmation email containing information about joining the Webinar.

Webinar System Requirements
PC-based attendees
Required: Windows® 2000, XP Home, XP Pro, 2003 Server, Vista

Macintosh®-based attendees
Required: Mac OS® X 10.4 (Tiger®) or newer

 

0 Comments Permalink
1

I've heard a number of interesting ideas around Basic System Defense usage.  Basic System Defense is the feature that allows you to define up to 32 inbound and 32 outbound ports of allowed traffic.

 

As a teaser to the article series, see the following diagram and brief explanation:

 

overview.gif

  • Target Client Computer - Unbeknownst to the user, the system has an outdated security solution and has been infected by a virus\worm. The user is experiencing delayed performance and unexplained events which prompt a call to the IT Support Helpdesk.
  • IT Support Technician - Receives support request to address the user's system troubles. Early diagnosis reveals the system has been infected. The user's system must be isolated from the network, meaning that communications in or out of the client must be restricted and remediated. The support technician will be using a Microsoft remote desktop to interact with the remote client computer, and will need to install files from a network share. (A similar concept would apply for PC Anywhere… yet to demonstrate the capability, I purposely chose this setup. Please keep reading)
  • Altiris Notification Server - The technician accesses the Altiris Console to invoke a Network Filter. However, the default network filter limits traffic to a very limited set of functions between the Notification Server and a target Intel® vPro™ technology system. If the standard Network Filter is used, Microsoft remote desktop and file transfer will be restricted. Therefore, a customized network filter is required, which is provided via the Altiris Enterprise Network Filter (ENF) Utility. The customized filter will allow Microsoft remote desktop ONLY between the IT Support Technician PC and the Target Client Computer. (NOTE: The ENF is a free add-on for Altiris v6 environments, and included in Altiris v7 environments.

 

 

Interested to read more on this, obtain sample configuration files, and understand how additional usages can be accomplished?

 

Take a look at the following series - I've included the individual links, but each article also includes the pre\post links within the series:

 

If you have additional ideas on use System Defense - please share

1 Comments Permalink
0
Perhaps a better question is - How can the current Intel vPro Technology combined with existing management\security solutions help protect client systems?

 

This is not an attempt to scare or over-generalize the reality of security threats such as the Conficker worm.  The intent is directed to how a real-world situation can be addressed.  The suggestions below assume Intel vPro Technology is already configured within your environment - thus you are ready and able to use the out-of-band management technology in connection with existing "in-band" management tools.
An overview of the Conficker worm is available online. The following are a few examples:
·         http://www.symantec.com/norton/theme.jsp?themeid=conficker_worm (there’s a 60 minute interview video)
There are a mix of good\bad reports on preventing, detecting, removing, and basically addressing the worm.
The following are a few suggestions on how to combine Intel vPro Technology with client management and security solutions to help protect and remediate a worm infection situation.
Interested to know if you’ve employed such tactics and how these have assisted in combating the Conficker worm threat.
·         System Defense/Network Filtering to totally isolate a client - For systems that have been detected as infected on the network
·         Out-of-band discovery of systems needing a patch – In searching databases\logs for clients that have not received the latest security updates, the ability to locate those system on the network even when powered-off
·         Wake-up, patch and/or scan systems – using a job to reliably power-on via Intel vPro technology, distribute necessary security patches to the client, run security scans, and then power-off the client.
·         Isolate and patch – For systems that have not been patched\scanned, yet to provide a security precaution before allowing them on the network. This will require a customized system defense or network filter to allow certain “in-band” actions on the targeted client. (i.e. patch, scan, etc).
If not already familiar with how to combine out-of-band and in-band management techniques as mentioned above, example demonstrations for an Altiris CMS version 6 environment are available at http://www.symantec.com/connect/articles/combining-band-and-out-band-management, with the same material (including lab documents) also posted at http://communities.intel.com/docs/DOC-2347
0 Comments Permalink
0

Take a minute to provide quick feedback on your experience with Intel vPro and this website

 

A poll to the community has been added to the vPro Expert Center main page (see widget on left side) - http://communities.intel.com/community/vproexpert

 

...along with a separate poll on the activation page (Again, see widget on left side) - http://communities.intel.com/community/vproexpert/activation

 

If you have ideas or suggestions for future polls - add a comment.

 

Look forward to seeing responses from the community

0 Comments Permalink
2

I hear the following scenario and question a lot - "All I want to do is remotely power-on a provisioned Intel AMT system. My target client management environment does not have Intel AMT functionality. If I could just script a remote power-on command, that would be very helpful. Is there a way to script the command?"

 

The short answer is yes - Take a look at http://www.symantec.com/community/article/6546/scripting-intel-amt-remote-power

 

Enjoy

2 Comments Permalink
0

If you are near Columbia, Maryland and want to attend a hands-on learning event - register at the link below

 

http://www.syssrc.com/html/training/FreeSeminars.cgi?function=seminars&seminar=512

 

Reducing Desktop and Mobile Operating Costs: Altiris with Intel vPro

Sponsored by System Source

Presenters include Symantec and Intel

9:00 a.m. - 2:30 p.m.

Columbia Hilton Hotel, 5485 Twin Knolls Rd, Columbia, MD. -Directions: 410-997-1060

0 Comments Permalink
2

At ManageFusion Orlando and in The Hague, we did a hands-on lab which combined Intel vPro System Defense capabilities, customized network filter from Altiris, and Altiris Software Delivery to securely update a client(summary available at http://juice.altiris.com/node/5721)

 

One of the attendees pointed out the following real-world challenge: They are migrating from one security solution to another. This will temporarily expose their client systems to attacks. With the capability to do secure updates – as noted in the lab – they are much better positioned to do to the migration for vPro\AMT enabled systems.

 

If you’re unsure what 5 minutes “in the open” can do to unsecure client – read the following news article entitled “Malicious ‘botnets’ turn PCs into ‘zombie’ slaves” - http://www.oregonlive.com/business/oregonian/index.ssf?/base/business/1224564910237820.xml&coll=7

 

Another attendee provided more reference to how they could use this. A classic "chicken/egg" problem - if a client is out of compliance or infected, it must be patched. The patch solution is on the production network, yet corporate policy states systems out of compliance are placed on an isolated or remediated network. So - how do you patch a client to which the production software delivery server cannot connect? Sneaker-net shouldn't be the answer... especially when the target client system is far outside the building you're in.

 

The key to remember about this use case - the System Defense filters must allow communications on the software delivery network ports. The Altiris Juice article above provides references on this is done in a Symantec\Altiris environment

2 Comments Permalink
1 2 3 Previous Next