The User Manual is here - you can find it under the Products / Admin Toolchest section on the Universal Login Script page.

Many companies today need to adhere to PCI or HIPAA guidelines to protect sensitive information. I'm not sure what the UK equivelent of these standards are, but they likely exist. Do you maintain confidential information about your employees on the computer network? This is often needed if you provide benefits (medical/dental, etc). These providers can require that your network meet specific security levels. If you process credit cards, you might need to meet PCI compliance. Both of these standards require that each user have a unique identity on the network. Using computer-based logins instead of user logins violates this, as it does not identify a specific user. This could result in fines of $10-25 thousand dollars in the US. Not insignificant.

It isn't difficult, but does take some thought.. I have a small client - 1 physical server, 4 VMware servers, and 8 employees. They passed a fairly rigorous HIPAA audit last year that some of my large clients are struggling with. The difference? We started out by setting security standards high when we rolled out their network, rather than doing it later. It added a day or so of discussion and planning to the network deployment - not a big thing.

Lets keep the concept of deploying per-computer settings simple. You can build from the concept to anything you need. For now, let's assume that every computer needs a unique ID number entered into the software. This can be in the registry or a config file, but let's go with registry.

Your login script - kixtart.kix - and the kix32.exe are placed in the \\domain\netlogon share. The PCRegister.ini file is placed there as well, and it contains a simple list of computer to ID number references. It would look something like this:

Code:

[APPLICATION]
Computer1=abc123
Computer2=123abc
Computer3=789xyz

Of course, each "Computer#" line would actually be a computer name on your network. This defines the relationship between a PC and the data.

In your login script, you'd have a code block that basically did a lookup of the ID number by computer name:

Code:

$Code = ReadProfileString('\\domain\netlogon\PCRegister.ini', 'APPLICATION', @WKSTA)
$Rv = WriteValue('registry key...', 'ValueName', $Code, 'REG_SZ')

The first line represents "read from the PCRegister.ini file. Go to the APPLICATION section, find the @WKSTA value, and return the data from that location". The next line writes that unique data to the registry key:value.

That's a simple, one PC to one value relationship. If you needed to set, say, 3 values on each PC, you might do it this way. The INI file would look like this

Code:

[COMPUTER1]
Value1=this
Value2=that
Value3=something else

This format would be repeated for each computer. The code block would be

Code:

$File='\\domain\netlogon\PCRegister.ini'
$Value = ReadProfileString($File, @WKSTA, 'Value1')
$Rv = WriteValue('registry key 1...', 'ValueName1', $Value, 'REG_SZ')
$Value = ReadProfileString($File, @WKSTA, 'Value2')
$Rv = WriteValue('registry key 2...', 'ValueName2', $Value, 'REG_SZ')
$Value = ReadProfileString($File, @WKSTA, 'Value3')
$Rv = WriteValue('registry key 3...', 'ValueName3', $Value, 'REG_SZ')

This reads a value from the @WKSTA section of the config file and writes it to the registry, once for each value.

These are very simple examples. It's possible to have a variable number of values, and even store the Key and Value names in the config file. If you provide more information about what needs to be set per PC, we can provide more ideas about how to deploy this.

Glenn