Home > Intel Communities > Open Port IT Community > Intel® vPro™ Expert Center > Blog > Tags > remote

Intel vPro Expert Center Blog

4 Posts tagged with the remote tag
0

At the recent Symantec ManageFusion 2009, Symantec announced the general availability of Symantec Altiris Client Management Suite Version 7.

One of the new features in Symantec Altiris Client Management Suite Version 7 is support for Intel Centrino 2 with vPro technology's "Fast Call for Help."  The video below by Symantec's Senior Technical Manager Lee Bender is a demonstration of how an end-user would connect back to the Altiris Client Management Suite for remote diagnosis and repair of his notebook even though he connect boot into Windows and is outside of the corporate firewall.

To learn more about Intel's presence at ManageFusion 2009, please go to http://www.intel.com/go/managefusion/

0 Comments Permalink
1

         

Integrating VNC on Windows PE 2.0

                            Author: Trevor Sullivan

                      Company:    OfficeMax Corporation

                        Versions: 1.0 – April 24, 2008 – original document

Synopsis

Integrating VNC on Windows PE allows a remote user, such as a support person, to remotely control a Windows pre-execution environment, and perform administrative tasks such as deploying an operating system image, or diagnosing hardware and software problems using 3rd party tools. This image can be remotely booted in a LAN environment using the IDE-R feature of Intel AMT.

Requirements

  1. Microsoft Windows AIK v1.1 (downloadable from Microsoft)
  2. A working Windows PE 2.x CD (can be built from WAIK)
  3. UltraVNC 1.02 (downloadable from Internet)
  4. ImageX (to mount WIM files) - included with WAIK

Setting up UltraVNC

Install UltraVNC 1.02 on a development system

 

You can optionally install UltraVNC 1.02 to an Altiris SVS virtual layer to avoid making permanent changes to your development system

 

After UltraVNC is installed:

1.  Execute VNC in user-mode

2.  Run the following command: winvnc –defaultsettings

3.  You should be presented with a configuration dialog

4.  Set a password for VNC and choose to disable the tray icon

5.  Confirm the settings dialog, and stop Winvnc by running: winvnc –kill

6.  Extract the following registry tree: HKLM\Software\ORL (vnc.reg)

7.  Add the password to the default key

a.  Open the registry file (vnc.reg)

b. Create a new section (key) for HKLM\Software\ORL\Default

c.  Copy the password value from ORL to the Default key

Gathering Source Files

Copy the following list of files from the UltraVNC installation directory on the source computer into a separate working folder:

 

  • Authadmin.dll
  • Authssp.dll
  • Ldapauth.dll
  • Logging.dll
  • Logmessages.dll
  • Mslogon.acl
  • Unzip32.dll
  • Vnchooks.dll
  • Vnchooks_settings.reg
  • Vncviewer.exe
  • Winvnc.exe
  • Workgrpdomnt4.dll
  • Zip32.dll
  • Vnc.reg (from previous section)
  • Vnc.vbs (see below)

 

Trevor developed a short script to get around a problem with winvnc hanging when I’d execute it. This executes winvnc.exe asynchronously so that it continues to run in the background, but startnet.cmd will be allowed to continue. The script source is included below:

 

ScriptPath = Left(Wscript.ScriptFullname, len(Wscript.ScriptFullName) - len(Wscript.ScriptName))

set sh = CreateObject("Wscript.Shell")

sh.Run "regedit /s " & ScriptPath & "vnc.reg", 1, true

sh.Run "wpeutil disablefirewall", 0, true

sh.Run ScriptPath & "winvnc.exe", 1, false

Modifying the PE Disc

  • Mount WIM file on filesystem using ImageX
  • Copy all source files to folder on root of WIM mount path
  • Modify startnet.cmd to execute VNC vbscript using cscript.exe
    • Use the fully qualified path to the script file (eg. “cscript X:\vnc\vnc.vbs”)

Notes

  • Winvnc does not work under service mode on Windows PE; Winvnc must be run under user context
  • The registry value “password” must exist under HKLM\Software\ORL\Default, otherwise winvnc will prompt for a password upon startup

 

Trevor Sullivan

Systems Engineer

OfficeMax Corporation

1 Comments Permalink
1

As many of you may know, there are two ways of contacting Intel AMT: The remote network interface and the local LMS/HECI interface. These interfaces are very different; the remote interface that is available thru the wired and sometimes wireless Ethernet and is rich with features while the local Intel AMT interface is very limited. Intel AMT was designed this way from the start for security. Intel AMT acting as an IT agent on desktops and laptops could not be allowed to be meddled with by the local user or local applications that could try to use or deactivate Intel AMT. That at least was the original design intent.

 

Times have changed it seems and many users of Intel AMT don’t see local users and applications as being always hostile. There are many reasons why it would be very interesting to access all of the features of Intel AMT locally. For example

 

  • If the user changes the name of the computer is the OS, it would be nice to have a local agent sync up the Intel AMT network with the OS name automatically. This way, when the computer goes to sleep next, Intel AMT will report the correct new name.

  • Circuit breaker policies could be used as a local firewall implemented in hardware. Set it once and the gigabit network chip does all the filtering and counters at gigabit speeds.

  • On a mobile platform, wireless profiles could also be synched up automatically. The user adds a new wireless profile with a WPA key and this profile is automatically added to Intel AMT.

  • Enterprise provisioning of Intel AMT could be done entirely locally using local software removing the need for complicated centralized servers.

 

Instead of seeing the local user as hostile, the local application now cooperate to setup Intel AMT so that if something goes wrong, it’s ready to be used to recover the computer. All this and more would be possible if Intel AMT allows the local applications full access to all the remote interface features.

 

A local application can’t simply connect to TCP port 16992 or 16993 and access all of the Intel AMT features since the traffic has to flow thru the gigabit network interface. Connecting to 127.0.0.1 will not work, that will access the more limited local interface.

 

A solution is to use a reflection application like Intel DTK Network Reflector found in the Intel AMT DTK. This tool runs on a central always on server and simply reflects back all TCP connections back to the source on ports 16992 to 16995. Using this tool an Intel AMT console or even a web browser can connect to "http://reflector:16992" and log into its own Intel AMT remote services. However, there are issues with this solution: You need this reflector tool running and know where on the network it is running. Also, a rogue application could log into the remote interface and put an annoying circuit breaker policy to drop all packets, etc.

 

In the future, Intel AMT itself could be modified to allow all services on the local interface removing the need for the reflector. There are security considerations of course, but feedback from users of Intel AMT on this idea would be appreciated.

 

Ylian (Intel AMT Blog)

1 Comments Permalink
1

Watch this video series where a admired IT administrator teams up with a brilliant developer for a remote management solution. Where IT and Dev team up to battle the EVIL in order to deploy the right solution. There is action, drama, suspense .. and lots of fun. What else were you expecting "Romance"? Give it a peek and pass it along. Also, stop by the

Super Secret Organization

.

 

Background:

 

The super secret organization (SSO) is a elite covert services company where IT services and security issues are a matter of life and death. So begins the saga of a Whiz Dev, a brilliant developer, and IT smith, a genius IT administrator. Whiz Dev and IT smith must depend on each other to defend their honor, their company and the best kept secrets. And, we have the bumbling interno who is constantly looking to enter this secret world.

 

Episode 1 "IT smith meets the bumbling interno"

 

Episode 2 "Whiz dev and IT smith"

 

Stay tuned for the episode 3 --- "The fate of SSO"

 

Video thumbnail. Click to play Click To Play Episode 1

Video thumbnail. Click to play Click To Play Episode 2

 

1 Comments Permalink