Novell Home

Distributing to Laptops (or Desktops) Only

Novell Cool Solutions: Tip

Digg This - Slashdot This

Posted: 8 Mar 2000
 

Current Version: ZENworks 2

An on-going brainbuster is the question of how best to distribute an application only to laptops, or only to desktops. This is a tricky one. To be able to add this option to the System Requirements, the engineers need a fool-proof way to distinguish a laptop from a desktop. Several people have sent in some great suggestions, and here they are. If you have other ideas, by all means send them in...

Here's what we've got so far:


Todd Pope's Idea

A user asked how to tell the difference between a laptop and a desktop in the Ask the Experts area. In our environment we only have PCMCIA controllers on laptops (although there are add-in cards for desktops) so ...

On Win95 machines, the following key exists in the registry if there is a PCMCIA controller present:

"HKEY_LOCAL_MACHINE\Enum\PCMCIA"

For NT the following key is present:

"HKEY_LOCAL_MACHINE\System\ CurrentControlSet\ Services\ Pcmcia\Enum"

We use the login script to launch a MS Kixtart script which reads the registry determines the platform and takes the desired actions.

Scott Moseley's Idea

The only problem with Todd Pope's idea is that the registry key for NT exists in CurrentControlSet only if the user is logged in. If you want to distribute the application in a "Lights out" fashion, you should use ControlSet001.

Instead of using ENUM, we used the Start value to determine if the service was disabled (which would also indicate that it's most likely not a laptop). I like the ENUM check though. And instead of using Kixtart we use the System Requirements feature in the ZEN App object.

Our task was to modify the NT machines so they reboot instead of Shutdown when users shutdown their machines at night (which against our corporate policy because we use "lights out" distributions). This change could be a problem for Laptop users, so we had to find a way to tell who was who.

You have a great site. Thanks for all of the help!

Nigel Forward's Idea

Little trick that can also be used for detecting laptops.

Not foolproof by any means, but here we use 3com or Intel adapters for desktops and Xircom for laptops. The first 6 digits of the mac address is the manufacturer, this can be picked up in the login script. You can drop the digits to the right using the >> function in login scripts, then compare the string. Note, though, that larger manufacturers have more than one ID, but this isn't tricky to keep tabs on.

John Grahs' Idea

Regarding the Desktop v. Laptop discussion, a method that's worked for me is setting a DOS environment variable.

Simply enter this into autoexec.bat (on Windows 9x machines): SET LAPTOP=YES

I can then test for this using scripts before distributing apps, or even in the login script.

Martin Eils?e's Idea

In regards to the question how to distribute programs to laptops or desktops only, I use the following registry keys in application object requirements.

ON WINDOWS 95/98:

Type=Default

Key=HKEY_LOCAL_MACHINE\SOFTWARE$ {BS}Microsoft\Windows\ CurrentVersion\FS Templates

Name=

Value=Desktop (Or "Mobile" for laptop)

ON WINDOWS NT/2000:

Type=DWORD

Key=HKEY_LOCAL_MACHINE\ SYSTEM\CurrentControlSet\ Control\IDConfigDB

Name=IsPortable

Value=0x00000001 (Or "0" for Desktop)

Randy Heller's Idea

To find out whether you are installing to a laptop or W/S can ZENworks differ between a unit that has a PCMCIA Card or a regular NIC? The only way this would not work is if the laptop is installed into a docking station or a port replicator that has a regular NIC in it. Or if ZENworks can inventory for a PCMCIA port?????

Just a thought......

Shabbir Talib's Idea

Another easier method that could be used is the Machine Type variable which can be set through the Client Configuration Advanced Settings Tab. The login script has a variable for %MACHINE which can be used to distinguish the type of machine.

Ming Chan's Idea

I have another method for detecting laptops vs. desktops. We use Toshiba laptops here exclusively at our workplace. I use the following setting:

Key:

HKEY_LOCAL_MACHINE\Enum\ Root\*PNP0C01\0000

Value name: [Value exists]

BIOSName

Value data: [String, not equal to]

Toshiba

This prevents an AOT package from appearing on Toshiba laptops.

Trevor Palmer's Idea

In response to your article about telling the difference between desktops and laptops....

I have used the following solution with success.

Firstly, I downloaded and installed the EXIST and BOX utilities from the Cool Tools page.

Next, I create a file on every laptop in the C:\ and called it PORTABLE.FLG. I put some text in this file saying not to delete it. I also make it Read Only.

Now comes the tricky bit...

I enter the following into the Pre-Launch Script of the application in question...

#EXIST C:\PORTABLE.FLG
IF ERROR_LEVEL="0" THEN
#BOX 16;Error;Cannot run this application from the Network|Please try running it locally
TERM "1"
END
EXIT

A couple of notes...

  • The EXIT at the end is required, as the EXIST program will leave you with a non 0 error level. This will cause NAL to not start the app if the file doesn't exist.
  • The example that comes with the EXIST program does not work, use the above code instead.

This can also be changed for laptop only applications, just change the 'ERROR_LEVEL="0"' to 'ERROR_LEVEL <>"0"'.

So, if the user tries to run the application from a laptop then a box pops up with a meaningful message, followed by the unfriendly message from NAL and the application terminates.

This solution is not limited to laptops, it can also be used on other PC's that are relocated often or have local installations of network applications.

This is only required for ZENworks 1.1. On ZENworks 2, there are built-in prerequisites to do this.

Michael Raugh's Idea

Another thought on the issue of identifying laptops: nearly all business-grade laptops include a program to configure the custom hardware, ie IBM's ThinkPad Features or Toshiba's Hardware Setup. Looking for these executables will not only establish that the machine is a laptop but can also help to identify the model, or at least the manufacturer.

If you have questions you may contact Michael at mraugh@adventisthealthcare.com

Stephen Hawkins' Idea

Regarding the "Distributing to Laptops (or Desktops) Only" issue, we use the NETWORK_ADDRESS login script variable to determine if a client is dialing up or locally connected. During login script execution, if the client's network address is within the range of our dialin network segments address then NAL will not be executed. For example,

IF NETWORK_ADDRESS>"XXXXXXXX" and NETWORK_ADDRESS<"ZZZZZZZZ" THEN GOTO SKIPNAL

The main reasons we like this method are that the checking is done in one place, the login script, and the checking uses native login script commands so the login process can be as quick as possible.

Kenneth Nelson's Idea

On the ZEN question Laptop VS Desktop. One solution that might work well is to check the CPU signature. Most Chip manufactures design special chips for laptops, which have different signatures embedded in them. By determining the proc type you could determine if the machine was a laptop or desktop.

Stefan Ensing's Idea

To determine if something is a laptop or a desktop you could use the description field under the network neighbourhood icon identification tab. If you put the systems type in it, say HP Vectra 6/500, you can easily find out what kind of machine you're dealing with by querying the value of the Comment registry key in HKEY_LOCAL_MACHINE\System\CurrentControlSet\ Services\VxD\VNETSUP. This is more tamperproof than autoexec.bat.

Robert Spangler's Idea

This is in response to the "Detecting Laptops from Desktops" dilemma!!! First, I would like to say that I was disappointed that the question I posted over a year ago about this went unanswered. Some feedback at the time would have been EXTREMELY helpful.

Nonetheless, here's the solution that I came up with:

Using location profiles in NDS/ZEN/Client32 and DOS variables. This is not as "automated", like some of the other suggestions listed in your column, but hey...it might work for some...

What I did was create two location profiles in ZENworks and distributed them to the people who used laptops via policies. One profile was called "Local", the other was called "Remote" (pretty original 'eh??) Inside the location profiles, I set a variable (like local=1 or local=0). When the user fired up their laptop they would then choose whether they were connected locally or remotely. The last step was to add an IF...THEN in the login script for each container to accomodate the local=x variable and act accordingly.

The beauty of this plan was that the profiles and all necessary client configuration was taken care of using ZENWorks and pushed out to the clients automatically. This was nice since there were approximately 100-150 laptop users across the US. The obvious down-side was that the users needed to determine their location manually which inevitably led to some confusion at times and "accidents" at other times.

PS: The location variable/profiles worked well for a different reason: some users in a satellite office were connecting through a 56K link (no local server) which was too slow to push apps through. Rather than get creative with a group or separate NDS container, I gave them only the "remote" location profile which prevented them from receiving NAL delivered items.

Brett Knighton's Idea

In response to the question of how to distinguish a laptop from a desktop, check for the existence of Infrared ports and/or PCMCIA slots.

Jeremy Mlazovsky's Idea

In John Grahs' Idea on Desktops vs Laptops, John said:

"Regarding the Desktop v. Laptop discussion, a method that's worked for me is setting a DOS environment variable."

In NT/Win2k, you can also set the Environment Variables in My Computer | Properties | Advanced | Environment Variables.

Christian Goetz's Idea

Concerning Laptops/Desktops detection: Probably a good way of detection would be based on the MAC address. Based on the MAC address, you should be able to define what type of NIC is used by a pc (pcmcia, pci, ...). For additional information, you will need to refer to the NIC vendor(s).

Manfred Engels' Idea

Read about your problems to determine if a computer is a laptop or a desktop. Might not be foolproof, but I have a little loginscript that might help you. Here goes:

Mactest:
set type="Desktop"
if P_STATION>>5 = "000083f" then
set type="Laptop"
else
if P_STATION>>6 <> "000083" then
set type="Unknown"
end
end
write <type>

First, I've got to explain, we have a token-ring network and use Olicom token-ring cards.

First thing I check is the fact that all Olicom PCMCIA cards from Olicom start with '000083f'. So if I find a MAC addy that starts with this, I label it 'LAPTOP'.

If the MAC addy starts with '000083' and is not '000083f' it must be a desktop computer with regular NIC.

If the MAC addy is anything else, I don't know what NIC I found, and label the computer as 'Unknown'.

True, this seems a lot of work to determine what a computer is (Doing it from the loginscript that is), but how about you guys obtaining a list from all NIC producers and ask them how they label their NICS (in Olicom's case: 000083f=PCMCIA; all others that start with 000083=regular NIC). Put these addy's in a table and at login determine from this 'NIC ADDRESS START TABLE' what a computer is: Laptop or Desktop.

Dirk Huemmer's Idea

This is related to "Distributing to Laptops (or Desktops) only."

Instead of determining the device type in any way, we use ZENWorks 2 features only. We decided to do a quick upgrade from V1.1 because of some workstation features we needed - so distribution via WS or WS Group is a nice feature.

To take full advantage of ZEN's features we have to do an import of every workstation into NDS. At this time it's easy to add the new workstation to a WS group (we use a ws_DefaultDesktop for desktop devices only). You can do the same with laptops, of course. Then it's easy to associate any application to the group OR (extracted from the other ideas) you may create a pseudo-application which distributes some registry keys for later use in other application's system requirements. Finally I never have to walk around ...all is done with NWADMIN:)

Marek's Idea

One of the diffrences is the existance of file called

hibrn8.dat in C:\.

It is a huge file = RAM in your laptop. Desktops don't have it.


Comments and Additional Questions (Send us the answer, if you've got one.)

Ryan Flud wrote: This is a comment about the "Detecting the difference between laptops and desktops" question you have on your site. Ben D. mentioned trying to test for a battery. You guys wrote:

"Woo hoo, Ben. The engineers thought it was an excellent idea! On a Win98 laptop they found a file called power.drv. It was only present if it was a laptop in the C:\WINDOWS\SYSTEM directory (%*WINSYSDIR% for you macro freaks).

Also, they found a registry entry in HKEY_LOCAL_MACHINE\ System\ CurrentControlSet\ Control\InstalledFiles

Value called "power.drv"."

This doesn't seem to be true. I'm running Win98 Second Edition on a desktop and it has both the file and registry key. I would imagine this is because my motherboard has power management (it's turned off but the motherboard supports it) and Win98 detected this during install. I would think that the PCMCIA detection is probably the best method to determine if it's a laptop or desktop.


Novell Cool Solutions (corporate web communities) are produced by WebWise Solutions. www.webwiseone.com

© 2014 Novell