MyLogon: Setting-up a central document-store
For any step-by-step description we need a starting-point, so here we'll assume that you' already have a functioning network, in terms of the cabling (or wireless equipment) being in-place, IP-addresses asigned, and machines able to communicate with each other.
The network might be a newly-established one, or it might be one which has been around for a while and is using peer-sharing methods, and which you've decided to convert to a server-centric model.
If you don't yet have a network set-up at all, then there are some useful guides on windowsnetworking.com to help you with this aspect.
Acquire and Configure a Server.
Either select an existing machine to act as the server, or purchase/build one for the purpose. Key requirements for the hardware are:
The machine shall need to be running 24/7.
It should be reasonably powerful.
Adequate disk-space is important.
A means of backup, such as a tape-drive or external disk.
Software-wise, a true server OS is preferred. This could be Windows 2000, 2003 or 2008 Server, or Linux.
For very small networks, a desktop version of Windows such as XP Pro can act as a server. Desktop Windows versions do however have a limit of ten users (Pro/Business) or five (Home) which cannot be increased. Therefore, think carefully about any expected staff increases before taking this route.
These instructions mainly relate to Windows servers, the Linux setup differing somewhat in terms of how shares and users are established, though the same general principles apply.
Organize (partition) the disk-space:
Desktops often tend to be set-up with one huge partition taking-up the entire disk space. On a server, this is a very bad policy. Instead, if you are setting-up your server from scratch, I would strongly suggest creating a smallish partition for the server's operating system (say 10% of the disk space, but not less than 20GB) and assigning the rest of the disk as a second partition for data. Why? Mainly in the interests of repairability. Servers tend to accumulate vast amounts of data, and a reload of the entire server's data, perhaps several Terabytes, could take an extremely long time. In the event of a fault developing in the operating system, a single partition containing everything would have to be reloaded in-toto to effect a repair, whereas a separate, small OS partition can be reloaded quickly. If you're converting an existing computer into a server then you may not have this option, but never mind, a single partition will do. But if you have the option, create two partitions -one for the OS, one for shared data.Tip: When creating partitions, always ensure that the OS partition is the Active Partition. Failure to do so will lead to serious problems.
Install the Server OS:
The exact procedure will of course depend on the chosen OS. For the moment I suggest you setup only the base components. Other embellishments can always be added later.Preferably the server's software-install should be limited to only those packages needed to provide its functions. The more standard the better. Although it is possible to make the server double as a workstation, I strongly advise against allowing that. Only Administrators should be allowed access to the server console, and then only for the purpose of managing the server. Therefore the server should not have user-level software like Microsoft Office installed onto it. A Web browser may be useful for downloading packages, but this should not have plugins like Flash or Java, as these create additional security risks. A basic copy of Firefox is ideal.
When asked about useraccounts during the install, I would be inclined to have the Administrator, plus another useraccount which serves as the normal server-console logon, for admin work. Even though you are the server Admin, I would advise you not to use the literal Administrator account (or root on Linux) for this purpose. Instead, create an account called -perhaps- 'console' for server admin. These two accounts should have secure (non-guessable) passwords, and these passwords should never be given-out to ordinary users. Ensure that the 'password never expires' option is ticked on these accounts.
If using a 'desktop' OS such as XP Pro as the server, you need to turn off Simple File Sharing. This is found on the Tools>Folder Options tab of any Explorer window. Otherwise all users will authenticate as the Guest account.
-Should I install the Active Directory at this point?
In the standard networking model for Windows Servers, users cannot properly log-on to a server unless the computers they use are Active Directory member-computers. With MyLogon installed on the desktop computers, an Active Directory is optional, but not mandatory.There are pro's and con's to having an Active Directory on a server. Microsoft will be very keen to extol how the AD provides you with a centralised database of users, computers, printers, and everything else on your network, and how it also allows you to take centralised control of those resources. These features are of unquestionable benefit to large organisations with multiple sites throughout the world. For the smaller enterprise the benefits are less apparent, though, and if all of the desktops are within easy walking-distance of the server, then the advantages are nonexistent.
The downside is that the AD adds a very substantial layer of complexity to the server, making for a much steeper learning-curve for the less-experienced systems admin.
Besides the complexity, setting-up the Active Directory will entail answering a number of questions of a very fundamental nature relating to your business identity, your Internet presence, and so on. As you might only just be starting in business, you may not have finalized answers to these questions. Yet, the AD setup wizard will DEMAND answers from you.. and once these values have been set, it is surprisingly difficult to alter them. Thus, setting-up an Active Directory before the identity of your business has been finalized is a very unwise plan. Yet, you probably want to get that server up-and-running, and everything else thoroughly tested, before the grand opening day. For startup businesses, this is a major Catch-22.
As well as the complexity of the AD itself, a server hosting an Active Directory MUST act as a DNS server, and it is here that many of the difficulties arise, particularly for inexperienced admins. . DNS (the Internet protocol which resolves website domain-names into IP addresses) is a topic of its own right, and far from a simple one. If trouble arises with the Active Directory or DNS components of a server, then the odds of the typical small-business IT guy managing to fix it are frankly not too good. In most cases a consultant with experience in this area will have to be called-in. Needless to say, that will be expensive.
If you are using the Small Business Server (SBS) version of Windows Server, then you have no choice as the Active Directory is always set-up. On the Standard server-releases you do have the choice. My feelings are that for very small networks you are decidedly better-off without the AD. The exception may be if you intend to use the Exchange mailserver, which pretty-much mandates the use of the AD. For medium-sized networks the choice is yours, and may depend on exactly how things are to be set-up. In any instance you can always defer the decision, and add the AD later. The more problematic option is that of removing or repairing an Active Directory if you later decide that installing it was a mistake, or that the fundamental parameters such as the domain-name were poor choices, and need to be changed.
Create Shares:
Your server needs to have an authentication share. This is typically named 'netlogon' and may already exist, or may not. It should have Read permissions to Authenticated Users. It can be either on the system or data partitions. The netlogon share will typically hold the logon script, plus a small amount of other data relating to network initialisation. The disk space it uses is normally insignificant.Tips: Do not create your server shares inside user-folders such as (My) Documents. If you do you will run-into problems with file permissions. Create a new folder in the root of your data partition (or the root of C: if you have only one partition) and put your shares in there. Ensure that this folder has Read/Write file permissions to Authenticated Users.
On Windows, typing net share at a commandprompt will tell you which shares already exist.
On your data partition, (you did use two partitions, didn't you?)
create a number of shared folders to hold the data. Here I can
only offer general advice, requirements will vary considerably between
sites. Typically you will need a general-use share, one which all
users can read and write to. You will probably also want a share which
is readonly as far as network access is concerned, and to which the
files will be copied using the server console. This is mainly for
program setup-files, and so on which are useful in setting-up desktops,
but which (in the interests of virus-protection) the desktop computers
should not be allowed to change. Thus you might have:
Folder: D:\Documents Sharename: Shared Rights: Authenticated Users; Read/Write.
Folder: D:\Install Sharename: Install Rights: Authenticated Users; Read.
Note that I create these permissions on the share properties,
not as NTFS filesystem permissions. Here my advice differs from
Microsoft's. Avoid the use of filesystem permissions to control
access to shares, unless this is actually necessary.
A word about permissions:
I've already mentioned this above, but it's worth reiterating that the permissions we're describing here are share-permissions. On Windows machines they're found on the same tab as the share settings. To complicate matters, there are also another completely separate set of permissions, ones which apply to the files and folders on the disk itself, assuming that the NTFS filesystem has been used. These are on the "Security" tab of the folder-properties dialog. For the moment, leave these strictly alone. Although they have their uses in more-advanced systems, filesystem-permissions are very much more complex than the share-permissions, and it's extremely easy to fall-foul of them. On small networks, share-permissions give all of the control we need, and are easy to understand and manage.If you attempt to share folders on the system partition (C:) of the server, then you may run-into problems with the filesystem-permissions which already exist here. Hence this is another reason why two partitions are preferable. If you must have your shares on the C: drive, then you will have to check that the filesystem permissions on these folders do not inhibit access for network users.
One case where the use of filesystem-permissions comes into its own is in the creation of 'home folders' - These are a special class of shared folder which is private to the logged-on user, and typically serve as a replacement for the 'My Documents' folder found on standalone desktop systems. To create 'home folders' you need to firstly make a root-folder in your data partition. Call this 'home', 'user' or suchlike. The share permissions should be "Authenticated Users;Full" Note that it must be Full and not just read/write. The trick here is that the filesystem permissions on this folder are then specially set so that any subfolder created in here will belong to the useraccount (or actually, the logon-script process) which created it.
It's also worth mentioning that wherever possible you should use groups to assign permissions. This is easier to manage than assigning permissions to individual users.
Create accounts for your network users:
On the chosen machine, as things stand there will probably be an Administrator account, plus perhaps one account for logging-on at its console. To prepare the machine for use as a server, you need to create a new user-account for each member-of-staff who logs-on to a client computer. These should be ordinary user- accounts, they should NOT be Administrators or Power Users. Remember, these 'users' will never actually sit at the server console, the function of the accounts is purely to control access to shares.If at this stage you do not know the logon-names for all users, just create one or two test accounts so you can check the logon action. The rest can be added later.
One important point is that by default, Windows expects a new user to set a password at first logon. This is not a very suitable way to do things with MyLogon. It is also not very secure, since an interloper can take control of a new, paswordless account before the rightful owner establishes a password on it. Instead, Untick "User must change password at first logon" Tick "Password never expires" and set a secure password. It would be a good idea to use a 'password safe' program to store the passwords you set.
All of these users will typically be in the Users or Domain Users group, and nothing else.
The one point I cannot over-stress is that ordinary network-access users must never be members of any Administrators, Domain Admins or Power Users group on the server.
At some point you may decide to segregate users into specific groups, to make control of access-rights simpler. When this becomes necessary I would suggest creating new groups for this purpose, rather than using the ones which Windows supplies by default. For the moment though, let's keep things simple and put them all into the 'users' group.
In point of fact I find it much more convenient to create useraccounts from the commandline. The command is:
net user {username} {password} /add
If the user needs to be in a specific group, the command is:
net localgroup {username} /add
Write a logon-script.
In the netlogon share, create a logon-script. There are several froms
this can take, the most basic being a batch-file, which we'lll use as
an example. The logon-script is run by the workstations
immediately after the users log-on to them. Note that it is never
normally run by the server itself, and you should not in fact attempt
to run it on the server. Although a logon-script can do
many things, its main function is to connect the workstation to the
server's shares. The logon script is typically placed in the server's netlogon share, although it can also be stored locally in C:\Windows\Mylogon\ if you prefer to have per-machine scripts.
=== mylogon.bat ====
net use h: \\server\documents
net use i: \\server\install
net use u: \\server\home\%user%
Alternatively you can use the newstyle syntax, which will look like:
=== mylogon.mls ====
[Mappings]
H:=Documents
I:=Install
Test the backup.
One point often overlooked is the need to ensure that backups are working properly. Server-centric working offers many advantages, but it also creates a critical point of failure in that the server is now the only place where data is stored. Thus, backups are even more important than on a workgroup setup. Backup hardware and software is notorious for poor reliability. Whatever system you use, a full and thorough test is essential. This should include a test-restore of a small amount of data to a new location, and comparison of this data with the original.Configure the Client Computers.
Install MyLogon onto the workstations.Either use the GUI configurator to set-up mylogon for your network, or alternatively, copy a prepared MyLogon.ini file to each workstation's \Windows\MyLogon folder.
Initially, use the as-required mode until you're sure everything is working OK. Test the logon, and see that the user gets authenticated, and the logon-script runs.
Note that the process of logging-on will remove any 'persistent' shares the machine used to have, so if that might be a problem note down what they were before running MyLogon for the first time.
Check that the user-permissions work as expected.
Activate 'Logon at startup' mode once you are happy it's working.
Set-up Printing
Tip: If you're using networked printers, disregard any instructions that came with the printer which tell you to install special 'printer-wizard' software from a CD.
Instead, set the printer up using the TCP/IP printing mode. Alternatively, you can use the very similar (but not identical) LPR printing service. Either requires that your printer has an Ethernet or WiFi connection -You did buy a network printer, didn't you? - and a fixed IP address.
The printer's IP address is typically set on its
control-panel, or via an interface which you access with a Web browser.
The latter of course requires that you know the printer's default
IP address as supplied, in order to do the configuration. Yes, this is a slight catch-22. However, ff your network has an Internet router with
DHCP, likely the printer will have been assigned a temporary IP address
by this, and you can determine what this is by examining the router's
config-page in a browser. Once you have access to your printer's
settings, assign a static IP address within your range.
Get the driver: Before going further, I would suggest going to the manufacturer's website
and downloading the latest WHQL driver for your printer model. Drivers
provided on a bundled CD are often well out-of-date, and you have a
better chance of avoiding bugs if you get the latest. Look for the
straightforward 'inf based' or 'commercial grade' driver, not the one
for home users with a million gimmicks. Use WHQL drivers by preference
as these have been vetted by Microsoft and are less likely to cause
trouble with your computer. Note that Windows XP requires
different drivers from Vista or 7, and 64-bit versions -of either
class- require different drivers from 32-bit operating systems. Vista
drivers will generally work if a Windows 7 driver is not listed. Thus,
make sure you download all versions that you need.
Now, on the clients, select '"Add new printer" in the Printers and
Faxes Control Panel. When asked what interface to use, select 'Local
Printer' - NOT 'Network printer' Then, when asked for a port, select
'Create a new port' and "Standard TCP/IP Port" or 'LPR Port' as
appropriate. You are then asked to enter your printer's IP address.
When asked for the printer type, select 'Have Disk' and point Explorer
to the shared folder where you put the driver. The installer should
come back with one or more printer types for you to choose from. Once
selected, the driver should install itself.
This procedure sounds as if it might be more complicated than using a supplied 'Printer Wizard' but it actually takes far less time to do than to describe, and has significant advantages:
- You are using a standardized protocol, the same for all printers
- Printing does not load-down your server with unnecessary traffic, or waste licenses
- No need for invasive 'printer wizard' software on client computers
- Once working, TCP/IP printer communication very rarely gives trouble
Clean-up the old shares.
For existing networks with multiple peer-shares, here comes the hardest bit: You need to go round the whole network tracking-down peer-shared folders, and moving the data onto the server's shares. Then you need to adjust any shortcuts on the workstations which refer to the location of this data, so the shortcuts point-to the new location. This will neither be simple nor trivial, and you're bound to encounter one or two knotty problems with unexpected side-effects of moving the data. Once done, close the peer-shares or they'll just start to grow again like 'topped' weeds. There are free tools from sysinternals.com which may be of help in locating/enumerating shares.Finally, check that everything works.
If all is as expected, sit back and enjoy that cuppa. You earned it.