A few weeks ago, John Obeto published a very extensive review of HP's 2nd generation TouchSmart PC. The new HP TouchSmart PCs are a follow-up to the 1st generation HP TouchSmart PCs which were released in January of 2007. The 1st generation HP TouchSmart PC was one of the first consumer PCs that took advantage of features in Windows Vista such as Windows Media Center. John's review goes from unboxing and OOBE (Out-Of-Box-Experience) to several testing scenarios. While the HP TouchSmart PC is a consumer PC - John also discusses the "unintended" use of the HP TouchSmart PC for the Small Business.

  

On my recent visit to Disneyland to see the Innoventions Dream Home, I was able to play around with the new 2nd generation HP TouchSmart PC courtesy of HP. At the Innoventions Dream Home, today there is a mixture of 1st generation and 2nd generation HP TouchSmart PCs. HP hopes to replace all the 1st generation HP TouchSmart PCs with the new 2nd generation TouchSmart PCs at the Innoventions Dream Home in the coming months.

So what is the HP TouchSmart PC exactly? It is an all-in-one PC with a 22 inch widescreen display that has built in touch capabilities. That means you can essentially touch the screen and utilize applications that take advantage of the built in touch features.  HP ships a suite of TouchSmart applications that take advantage of touch but more about this in just a bit. 

The new HP TouchSmart PC ships with the following specs (complete list of details specs are listed here in this PDF):

Processor: Intel Core 2 Duo Processor T5850 (2.16GHz)
Chipset: Intel GM965 Express Chipset
Memory: 4GB DDR2 SDRAM
Hard Drive: 500GB 7200RPM SATA
Optical Drive: Slot-load SuperMulti DVD Burner
Video Graphics: NVIDIA GeForce 9300 M GS HD with 256MB Dedicated Video Memory
Network: 10/100/1000 BaseT network interface
Wireless Connectivity: Integrated Bluetooth / Wireless LAN (802.11b/g/n) with built-in WLAN antenna
Audio: Integrated High Definition Audio with High-performance 2.0 Speakers
TV Tuner: Dual-format NTSC or over-the-air ATSC High-Definition TV Tuner
Remote Control: HP Media Center Remote control with IR (infrared) Receiver
External Memory Port:  5-in-1 memory card reader

You'll notice the system ships with 4GB of RAM. Because of this - the HP TouchSmart PC also ships with Windows Vista Home Premium x64 to take advantage of the full amount of memory. The HP TouchSmart PC also ships with Windows Vista SP1 installed as well.

There are 2 models of the HP TouchSmart PC today: the IQ504t and IQ506t. The biggest difference between the two models is that the IQ506t is the model that ships with the TV Tuner built in.

The design of the 2nd generation HP TouchSmart PC is quite a bit different than the 1st generation. The main PC is a much sleeker design. HP describes the design as a "sleek piano black design with elegant espresso side-panel highlights". The unit also comes with a HP Ambient Light that allows users to see their keyboard in the dark. The keyboard is also conveniently able to be tucked under the unit when needed as well which is nice especially if you would like more room.

While the design of this all-in-one PC is impressive, equally impressive is the HP TouchSmart Suite that ships with it. The TouchSmart Suite consists of the following applications:

• HP TouchSmart Music
• HP TouchSmart Video
• HP TouchSmart Photo
• HP TouchSmart RSS Feeds
• HP TouchSmart Browser
• HP TouchSmart Calendar
• HP TouchSmart Notes

These applications take full advantage of the touch capabilities of the HP TouchSmart PC. Navigate through your RSS feeds with the touch of a finger. Go through your calendars by simply touching the screen. Play music, view photos, watch videos - all by touching the screen. In using these applications you can see that HP has invested a great deal in touch capabilities for this PC - which is very exciting. In my own experience trying these applications out myself - I found everything responds elegantly to the move of my finger on the screen. No lag, not hiccups what so ever. It was certainly a "wow" moment for me. If this PC was sitting in your kitchen or living room, to use it all you would need to do is walk up to it and touch the screen - no keyboard necessary.

Side-note: I'd like to note because this PC ships with Windows Vista Home Premium x64 - the TouchSmart Suite of applications work fully under 64-bit.

HP has invested quite a bit in touch technology for the PC. The HP TouchSmart PC is a culmination of 25 years of HP touch technology design and development. HP first brought a PC with touch technology to the market in 1983 with the introduction of the HP 150 PC.

For more details on the HP TouchSmart PC - check out HP's TouchSmart Website at www.hp.com/go/touchsmart. There you can view a demo of the HP TouchSmart PC's impressive capabilities. You may have also seen their ad on TV as well. If you want to check out the HP TouchSmart PC out yourself in person - the HP TouchSmart PCs can be seen in a variety of stores such as Best Buy, Fry's, and Circuit City. You can also see them, as mentioned above, at the Innoventions Dream Home at Disneyland.

Probably the most important thing that you can do when investigating a performance problem is to record every output that you see, every command that you execute, and every piece of information that you research. A well-organized set of notes allows you to test a theory about the cause of a performance problem by simply looking at your notes rather than rerunning tests. This saves a huge amount of time. Write it down to create a permanent record.

When starting a performance investigation, create a directory for the investigation, open a new "Notes" file in GNU emacs, and start to record information about the system. Then store performance results in this directory and store interesting and related pieces of information in the Notes file. Suggest that you add the following to your performance investigation file and directory:

• Record the hardware/software configuration— This involves recording information about the hardware configuration (amount of memory and type of CPU, network, and disk subsystem) as well as the software environment (the OS and software versions and the relevant configuration files). This information may seem easy to reproduce later, but when tracking down a problem, you may significantly change a system's configuration. Careful and meticulous notes can be used to figure out the system's configuration during a particular test.

Example: Save the output of cat /proc/pci, dmesg, and uname -a for each test.

• Save and organize performance results— It can be valuable to review performance results a long time after you run them. Record the results of a test with the configuration of the system. This allows you to compare how different configurations affect the performance results. It would be possible just to rerun the test if needed, but usually testing a configuration is a time-consuming process. It is more efficient just to keep your notes well organized and avoid repeating work

• Write down the command-line invocations— As you run performance tools, you will often create complicated and complex command lines that measure the exact areas of the system that interest you. If you want to rerun a test, or run the same test on a different application, reproducing these command lines can be annoying and hard to do right on the first try. It is better just to record exactly what you typed. You can then reproduce the exact command line for a future test, and when reviewing past results, you can also see exactly what you measured.

• Record research information and URLs— As you investigate a performance problem, it is import to record relevant information you found on the Internet, through e-mail, or through personal interactions. If you find a Web site that seems relevant, cut and paste the text into your notes. (Web sites can disappear.) However, also save the URL, because you might need to review the page later or the page may point to information that becomes important later in an investigation.


As you collect and record all this information, you may wonder why it is worth the effort. Some information may seem useless or misleading now, but it might be useful in the future. (A good performance investigation is like a good detective show: Although the clues are confusing at first, everything becomes clear in the end.) Keep the following in mind as you investigate a problem:

• The implications of results may be fuzzy— It is not always clear what a performance tool is telling you. Sometimes, you need more information to understand the implications of a particular result. At a later point, you might look back at seemingly useless test results in a new light. The old information may actually disprove or prove a particular theory about the nature of the performance problem.

• All information is useful information (which is why you save it)— It might not be immediately clear why you save information about what tests you have run or the configuration of the system. It can prove immensely useful when you try to explain to a developer or manager why a system is performing poorly. By recording and organizing everything you have seen during your investigation, you have proof to support a particular theory and a large base of test results to prove or disprove other theories.

• Periodically reviewing your notes can provide new insights— When you have a big pool of information about your performance problem, review it periodically. Taking a fresh look allows you to concentrate on the results, rather than the testing. When many test results are aggregated and reviewed at the same time, the cause of the problem may present itself. Looking back at the data you have collected allows you test theories without actually running any tests.

Although it is inevitable that you will have to redo some work as you investigate a problem, the less time that you spend redoing old work, the more efficient you will be. If you take copious notes and have a method to record the information as you discover it, you can rely on the work that you have already done and avoid rerunning tests and redoing research. To save yourself time and frustration, keep reliable and consistent notes.

For example, if you investigate a performance problem and eventually determine the cause to be a piece of hardware (slow memory, slow CPU, and so on), you will probably want to test this theory by upgrading that slow hardware and rerunning the test. It often takes a while to get new hardware, and a large amount of time might pass before you can rerun your test. When you are finally able, you want to be able to run an identical test on the new and old hardware. If you have saved your old test invocations and your test results, you will know immediately how to configure the test for the new hardware, and will be able to compare the new results with the old results that you have stored.

Source of Information : Optimizing Linux® Performance

Troubleshooting client self-update issues

If the client self-update does not work automatically, use the following suggestions to troubleshoot the problem.

How to differentiate between the SUS client and WSUS client

Use the Automatic Updates user interface (UI) to differentiate between the SUS and WSUS clients. The following illustrations show the user interface of the SUS and WSUS clients.

Verify that the client software in your organization can self-update

Some computers might already have the WSUS client installed. Other computers might have a version of Automatic Updates that is incapable of performing self-update. For more information see Deploying Microsoft Windows Server Update Services. If the clients in your organization are capable of and require self-update, but are still not self-updating, see the next section.

Verify that the SUS clients are pointed to the WSUS server

If you have the WSUS client installed but the client computer is pointed to a SUS server, Automatic Updates falls into legacy mode and the client computer uses the SUS client user interface. In this case you need to redirect the computer away from the SUS server to get the WSUS client to function. When you point Automatic Updates away from the SUS server, it automatically comes out of legacy mode and the new client user interface appears.

If your client computers are pointed to the WSUS server and you do not see the WSUS client user interface shown above, see the next section.

Check for the selfupdate tree on the WSUS server

WSUS uses IIS to automatically update most client computers to the WSUS-compatible Automatic Updates. To accomplish this, WSUS Setup creates a virtual directory named Selfupdate, under the Web site running on port 80 of the computer where you install WSUS. This virtual directory, called the self-update tree, holds the latest WSUS client. For this reason, you must have a Web site running on port 80, even if you put the WSUS Web site on a custom port. The Web site on port 80 does not have to be dedicated to WSUS. In fact, WSUS only uses the site on port 80 to host the self-update tree.

To ensure that the self-update tree is working properly

1. Confirm that there is a Web site set up on port 80 of the WSUS server.
   
2. Type the following at the command prompt of the WSUS server:
   

   cscript WSUSInstallationDrive:\program files\microsoft windows server update services\setup\InstallSelfupdateOnPort80.vbs
   

3. If you have WSUS client self-update running on port 80 of the WSUS server, see the next section.
   

Check IIS logs on the WSUS Server

Check the IIS logs on the WSUS server. IIS logs are typically located in %windir%\system32\LogFiles\W3SVC1 for the default Web site. If you copied the Wutrack.bin file to the \InetPub\wwwroot folder on the WSUS server when you set up client self-update, you can open the IIS logs and search for Wutrack.bin to attempt to locate error messages about why self-update is failing. Typical errors might be 404 (file not found) 401/403 (authentication/access), and 500 (Internal server error). Use IIS Help to troubleshoot any problems found in the IIS logs.

If you have installed Windows® SharePoint® Services on the default Web site in IIS, configure it to not interfere with Self-update

If you install Microsoft Windows Sharepoint Services on the same server that is running WSUS, you might get the following issues:

• An "Access denied" message appears when Automatic Updates tries to update itself, and the latest Automatic Updates will not be running.
  
• On the Home page, a message appears warning you that the SelfUpdate service is not available.
  

If client computers are not running the WSUS-compatible version of Automatic Updates, they will not be able to receive updates through WSUS.

To resolve this issue

1. Grant Anonymous access (Anonymous Auth) to the Default Web site, ClientWebService and Selfupdate v-roots in IIS.
   
2. Exclude specific requests from being intercepted by the Windows Sharepoint Services ISAPI DLL by doing the following:
   
   1. Open the Windows Sharepoint Services Central Administration Site (click Start, point to Administrative Tools, and then click Sharepoint Central Administration).
      
   2. Click Virtual Server Configuration, and then click Configure Virtual Server Settings.
      
   3. Click Default Web Site.
      
   4. Click Virtual Server Management, and then click Define managed paths.
      
   5. In the Add a new pathbox, set the type to excluded path. Under Path, type the following:
      "/iuident.cab"
      "/wutrack.bin"
      "/clientwebservice"
      "/Selfupdate"
      

Check network connectivity on the WSUS client computer

Check network connectivity on the WSUS client computer. Use Internet Explorer to determine if self-update files on the WSUS server are accessible to the client computer. If you perform the following procedure and are prompted to download or open the files, you have verified network connectivity. It is not necessary to save or open the files. You cannot self-update Automatic Updates this way. If you do not have access to these files, troubleshoot network connectivity between the WSUS client computer and the WSUS server.

To check network connectivity on the WSUS client computer

1. Click Start, and then click Run.
   
2. In the Open box, type iexplore and then press ENTER
   
3. In the Internet Explorer Address bar, type:
   

   http://WSUSServerName/iuident.cab
   

   where WSUS server name is the name of your WSUS server. Ensure that you are prompted to download or open Iuident.cab. This verifies network connectivity from the WSUS client and the availability of the Iuident.cab file on the WSUS server.
   

4. If there are any boxes prompting you to download or save, click Cancel. In Internet Explorer Address bar, type:
   

   http://WSUSServerName/selfupdate/AU/x86/osvariable/languagevariable/wuaucomp.cab
   

   where WSUSServerName is the name of your WSUS server and where osvariable is a variable indicating the operating system of the client computer. The possible variables for osvariableare NetServer, W2K or XP, and where languagevariable is a variable indicating the language of the operating system of the client computer. The possible variables for oslanguage are based on the standard 2- to 4-letter language abbreviations. For example, here is a URL for a client computer running an English version of Windows XP:
   

   http://WSUSServerName/selfupdate/AU/x86/XP/EN/wuaucomp.cab
   

5. Ensure that you are prompted to download or save Wuaucomp.cab. This verifies network connectivity from the WSUS client and the availability of the Iuident.cab file on the WSUS server. If you are prompted to save or download both of these files, see the next section.
   

Check logs on the SUS client computer

Check the %windir%\windows update.log on the client computer to see if there has been any activity or any attempts to contact the server. Check the %systemdrive%\program files\windowsupdate\v4\urllog.dat file on the client computer for cached server pingbacks if the client computer has not been able to communicate with the server.

These files are hidden by default. Use the following procedure to display hidden files and folders in Windows Server 2003.

To display hidden files and folders on Windows Server 2003

1. In Control Panel, open Folder Options.
   
2. On the View tab, under Hidden files and folders, click Show hidden files and folders.
   
3. If you can find no problem with the logs on the WSUS client, see the next section.
   

Manipulate registry settings on the SUS client computer

If all else has failed, you can attempt to manually manipulate registry settings to get the client computer to self-update to the WSUS client.

To manually manipulate registry settings on the SUS client computer

1. Click Start, and then click Run.
   
2. In the Open box, type regedit and then click OK.
   
3. In Registry Editor, navigate to the WindowsUpdate key by expanding the following:
   

   HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\
   

   If the WindowsUpdate key does not exist, do the following:
   

4. On the menu, click Edit, point to New, and then click Key.
   
5. Type WindowsUpdate as the name for the new key.
   
6. Double-click the WUServer setting, type the URL to your WSUS server, and then press ENTER.
   

   If the WUServer setting does not exist, do the following:
   

   On the menu, click Edit, point to New, and then click String Value.
   

7. Type WUServer as the setting name.
   
8. Double-click the WUStatusServer setting, type the URL to your WSUS server, and then press ENTER.
   

   If the WUStatusServer setting does not exist, do the following:
   

   On the menu, click Edit, point to New, and then click String Value.
   

9. Type WUStatusServer as the setting name.
   
10. Navigate to the following:
    

    HKEY_LOCAL_MACHINE\Software\Policies\Microsoft\Windows\WindowsUpdate\AU
    

    If the AU key does not exist, do the following:
    

    On the menu, click Edit, point to New, and then click Key.
    

11. Type AU as the name for the new key.
    
12. Verify that the UseWUServer setting has a value of 1 (0x1).If it does not, modify it by double-clicking the setting and then changing the value.
    

    If the UseWUServer setting does not exist, do the following:
    

    On the menu, click Edit, point to New, and then click DWORD Value.
    

13. Type UseWUServer for the setting name.
    
14. Navigate to the following:
    

    HKEY_LOCAL_MACHINE\Software\Microsoft\Windows\CurrentVersion\WindowsUpdate\Auto Update
    

15. Enable and configure Automatic Updates through Control Panel:
    

    Click Start, click Control Panel, and then double-click Automatic Updates.
    

16. In the Automatic Updates dialog box, specify download and installation options, and then click OK. Make sure that Turn off Automatic Updates is not selected.
    
17. Ensure that the AUState setting has a value of 2 (0x2). If it does not, modify it by double-clicking and changing the value.
    
18. If the LastWaitTimeout setting exists, delete it.
    
19. If the DetectionStartTime setting exists, delete it.
    
20. At the command prompt, type the following, and then press ENTER to stop the Automatic Updates service:
    

    net stop wuauserv
    

21. At the command prompt, type the following, and then press ENTER to restart the Automatic Updates service:
    

    net start wuauserv
    

22. Wait approximately 6 to 10 minutes for the self-update to occur.
    

To force the SUS client computer to check with the WSUS server

1. Wait approximately one minute, and then refresh the registry. You should now see the following settings and values:
   

   DetectionStartTime (REG_SZ) YYYY.MM.DD HH.MM.SS. The DetectionStartTime value is written in local time, but the detection actually occurs 5 minutes after the time noted.
   

   LastWaitTimeout (REG_SZ) YYYY.MM.DD HH.MM.SS. The LastWaitTimeout value is written in GMT or Universal Time, and represents the actual time that detection occurs.
   

   Although these values refer to the time that detection is going to start, the first phase of detection is the process of checking whether a self-update is necessary. Therefore, these values actually refer to when self-update from the SUS client to the WSUS client should occur.
   

2. If the client software has not self-updated after ten minutes, refresh the \Auto Update registry key. If the LastWaitTimeout value has changed and is now 24 hours later than its previous value, that indicates that Automatic Updates was not able to contact the server URL that you specified in the WUServer value.
   

Microsoft has formally announced its new Windows marketing campaign. I'm baffled. Are you?

source: microsoft-watch.com

A task is a personal or work-related errand you want to track to completion. A task can occur once or repeatedly (a recurring task). A recurring task can repeat at regular intervals or repeat based on the date you mark the task complete. For example, you might want to send a status report to your manager on the last Friday of every month, and get a haircut when one month has passed since your last haircut. For more use Outlook Support.

To create a task you must first select the Tasks container in the Folder List or Outlook

Bar.

Follow the steps to create a task

1. Click Tasks from your “Folder List” or “Shortcuts”.

2. Click New (left corner).

3. In the “Subject” field Type Test1.

4. Use the down arrow to select a due date one day from today’s

date.

5. Click Save and Close.

You can use also

1. In any open space in the “Task” window double-click to open a

new task.

• Notice you have opened a new task two different ways.

2. In the “Subject” field Type Complete lab 5.

• “Due date” field enter today’s date.

• “Start date” field enter today’s date.

• “Status” click the down arrow and click In Progress.

3. Check the “Reminder” box.

4. Set the “Time for completion” box to the next half hour from the

computer’s time.

5. Click save and close.

If you think Live Mesh is just about syncing some TPS reports across a couple of computers and maybe a mobile phone or two then you’re a very narrow-minded person.

Bit and pieces of information about what else Mesh can do has been scattered around various Channel9 videos like this one with Ori Amiga all the way back in April, but I wanted to see where they’re at now so I lurked around the Live Mesh booth last week at the Microsoft TechEd Australia conference.

Fortunately my good charms paid off when Angus Logan - Senior Technical Program Manager for Windows Live Platform - gave me a quick but satisfying peek into the world of applications running on the Live Mesh platform coming soon to both end-users and developers.

Please bear in mind any of the following is subject to change and your mileage may vary.

As you can see from the above screenshots, the same demo Mesh application “Tracker” - a simple to-do list app can be run from both the Mesh desktop in the browser and on the actual Windows desktop as a (sort of) real application. To achieve this run-everywhere application experience, the Mesh apps on the desktop actually run inside a chromeless Internet Explorer wrapper provided by the Mesh Operating Environment (version 0.9.3104.1 for those of you playing at home). Ignore the bug with the Mesh panel on the desktop thinking it’s a folder.

Not only can you have the same application run in multiple devices and even just inside a web browser, it also syncs data across all devices autonomously thanks to the underlying Mesh framework. Furthermore even if the network is unavailable, due of the way Mesh manages data, the application’s data and the application itself will still be available with the latest version of the data it was able to sync.

Now obviously a to-do list application is a pretty straightforward example of where synchronicity might be useful, but imagine where this could go. Having heard some people talk about just how difficult it is to move a music library from one computer to another, imagine storing your entire music collection on Mesh and managing it with a Mesh application allowing you to enjoy and manipulate the same library and playlists across all devices wherever you are, even if you’re at a friends’ house with just a browser.

For the programming-minded amongst us who can’t wait to get their hands dirty, then keep your eyes locked on Microsoft’s Professional Developers Conference in late October where the Live Mesh SDK should be making an appearance.