'A proper network logon for your users..  minus the rocket-science.'

MyLogon is a user-logon applet for Windows, aimed at small to medium-sized networks. It was coded in-reponse to an observed need for a straightforward and  effective method of connecting  small-business computers to a fileserver, one which meets the typical requirements of a 5-50 user site, but does not require an extreme level of technical expertise to deploy or manage. 

Typical small-network Requirements:

That users should always be required to log-on to the server to gain access to shared documents.

That an administrator should have full and flexible control over shares, usernames and passwords.

That users can stand-in for absent staff without having to know their password.

That  shared resources should be presented to the user in an easy-to-understand manner.

The facility to run scripts at logon, for the purpose of updating client software, etc.

That the computer, if portable, can be used at more than one site.

That the computer can be used away from any fileserver, without problems.

That the network should be tolerant of a  'mixed bag' of differing computer specs.

That a computer can join or leave the network without losing the settings for its software.


In order to understand why a new approach was considered necessary, it is first necessary to look-at where the existing options fail to meet these objectives:


Workgroups:

Small collections of linked computers, typcially those of ten or less desks, will generally tend to be using a workgroup topology. In this, no fileserver or central data-store exists, each user storing their data in the "My Documents" folder of the local computer. If other users need access to these files, this is achieved by way of sharing the "My Documents" folder across the network.

The disadvantages of this model soon become apparent. Storing electronic documents  in numerous disparate locations is not unlike scattering their paper equivalents all around the office. (Under the feet of chairs, behind the backs of cabinets.. catch my drift?)  It is self-evident that documents so treated will soon become lost or accidentally deleted. Furthermore, because of the haphazard method of storage, staff will waste a large part of their working time searching for mislaid documents.  What is needed is  the electronic equivalent of a filing-cabinet in which the documents are centrally stored, in an organised and easy-to-find manner. A fileserver fuilfils this role.

Active Directory:

Microsoft's answer to the limitations of workgroups is the Active Directory Domain. This approach, which will naturally require a bona-fide server platform as its host, offers a wealth of features aimed at making life easier  for the adminstrator of a large corporate site. Individual computers are 'joined' to tthe Active Directory Domain, and from this point on the computer's owner effectively reqlinquishes control of all elements of that computer's config and maintenance to the network administrator.

Whilst this situation may be ideal for the very large site, its shortcomings become very apparent on smaller sites. Notable issues which arise are:

Active Directory setup demands that  you provide detailed information about your Internet presence, company naming-conventions, and so on. Once set these parameters are hard to change, therefore you must get them right first time.

Joining an existing computer will mean the loss of its configuration, reverting it to what is effectively a 'fresh out of box' setup. This can be worked-around, but  the 'fix' is complex and time-consuming. Dis-joining  will likewise trash its configuration.

From the installer's point of view, Active Directory membership means that  computers cannot be preconfigured for delivery. Instead, they must be set-up almost from scratch at the customer's site on the desk where they will be used, no matter how inconvenient that may be. This arises from the fact that the setup 'wizard' will  not permit you to configure Active Directory membership unless a direct connection to the domain-controller server exists at that time. (Presumably the designers of the Active Directory did not see this as a problem, since all businesses have onsite IT staff and workshops... don't they?) 

Most of the Active Directory administration-tools, whilst extremely powerful, are way too complex for the typical small-site admin to master. This tends to nullify most of their touted advantages.

It is best suited to large banks of identical and 'anonymous' computers. It does not so well suit  diverse collections of computers, all bought at different times and having differing specs and different software installed.

Even quite trivial mistakes in Active Directory configuration can leave gaping security holes.

Because of user-profiling, it is difficult to stand-in for an absent user without knowing that user's password. (using a different logon will work, but will generally result in nothing working properly owing to software-settings having defaulted.)

If it breaks, the odds of being able to fix it yourself are not good. Most likely you will have to call-in a consultant.

So, Active Directory membership, while answering many of the shortcomings of Workgroups, has its own problems as far as the smaller business without dedicated IT staff is concerned. Yet, Microsoft offer no halfway-house, you either stick to the overly simplistic Workgroup, or else step boldly forward into the rocket-science that is Active Directory networking. 

MyLogon offers a third alternative, a means of centralising your data storage, but without the need to join your computers into an Active Directory Domain.

It does not, in fact, matter whether the server is setup as an Active Directory Controller, or a simple server. MyLogon copes with both situations. For multi-server sites it may be an advantage to join the servers into an Active Directory forest. Doing things the MyLogon way does not however demand that the client computers also join the domain.

Where MyLogon differs from the corporate Domain approach is that its feature-set is confined to those items typically required in smaller networks. There is thus no need to grapple with the complexities of - for example - DNS administration, Roaming Profiles, or Group Policies. Furthermore,  joining of a computer to a MyLogon network is by-and-large a painless operation, with NO loss of settings, and NO loss of access to existing local files. Disconnecting the computer from the network is equally simple and side-effect free.

Under MyLogon, network resources are allocated via a logon script.  Via this script, network resources are seen as mappings - additional driveletters in My Computer or Explorer. This choice is based on user-feedback, which indicates that most people strongly prefer drive-letters (or UNC shortcuts) over having to use the at-best unpredictable  "My Network Places" tool.

In terms of user-rights, a key advantage is the ability to make each user an Adminstrator of their personal computer, without this causing network-security issues.  On sites without permanent IT staff this is generally a requirement, as the user must be able to install and configure software.  Being in full control of their own PC doesn't however mean having the same rights across the network, as it so often does in an improperly-setup Domain.  Users can still be given limited rights to their own computers, of course, if that is preferred.

Security has been given careful thought, and while MyLogon doesn't require faddist  measures such as frequent password-changes, the design tries to avoid situations such as the saving of passwords to network-shares on the user's own computer - a feature which creates serious risks in the standard model.  The options also include the ability to turn-off a number of the more vulnerable centralised-admin features of the standard model,  since these are rarely used on small networks,  but constitute a serious security problem.

Linux Servers:


The use of Linux as a server platform is becoming ever more popular. This is understandable in view of that platform's good security and stability, and its relative freedom from restrictive and expensive licensing schemes.

A limitation, though, is that Linux servers using the Samba service do not provide full Active Directory support. In fact, their networking support is more akin to the model employed by Windows NT4.  The main impact for the small business is that  joining a Windows XP computer to a Linux/Samba domain involves even more manual reconfig-work than for the Windows Server equivalent.

MyLogon fully supports Linux/Samba servers. It should therefore be self-evident that taking the MyLogon route to Linux server connectivity will save substantial amounts of time and effort over the painstaking alternative of manually joining Windows computers to a Linux/Samba domain.

Existing Computers:


A key advantage, as we've mentioned, is in the case of existing computers joining a server-based network for the first time. With the domain model this means every user losing access to their files and settings, since the domain user-profiles are not the same as those used when used standalone, or in a  workgroup.  This can be worked-around, but is complex and time-consuming to fix.  With the MyLogon approach it's a non-issue, the user is free to work attached to the network, or separately.

Background Considerations:

In terms of its design, Microsoft Windows caters very well for the home user or very small workgroup, and also for the large corporate site with hundreds of networked computers. Intermediate sizes of network are not so well-supported. The Workgroup approach favoured by SOHO networks quickly becomes chaotic with more than a handful of computers.  Meanwhile the Active Directory model favoured by corporates, while extremely powerful and effective, is costly and overcomplex when applied to a smaller site.

Experience soon shows that neither approach is well-suited to the small or medium sized business, One being too simplistic and uncontrolled, the other requiring resources such as a permanent IT staff, that a firm of this size simply cannot justify. 

 It is also true that MyLogon will not suit every situation, in some cases the standard approach will be more suitable. As always when planning a network, this cones-down to a question of evaluating the requirements and the best ways to fulfil them.  At least, the network engineer now has an option aimed at the smaller site's requirements, whereas previously no such option existed.



The Differences between MyLogon and the standard Windows Logon

There are several  key differences to the way in which MyLogon connects the computer to the server:

The downside (if it is one) of the MyLogon approach is that computers which  are shared between more than one user cannot be 'personalised' for those individuals.  All users of a given computer will see the same desktop, screensaver, favourites, etc.  This might at first-sight seem like a problem, however experience shows that sharing of computers in the office is in fact extremely rare. Almost all business computers are allocated for the sole use of one individual.  Hence this customisation - or profiling, as it is known - is seldom actually required.  Yet, it imposes a tremendous burden of  complexity on the network, and raises all kinds of knotty problems.

For situations where we don't need this user-by-user customisation of the computer, MyLogon offers a simpler, faster, more functional alternative.

Windows XP Home computers are able to properly join the network  too,  while Microsoft's approach  limits such computers to a very basic form of networking.

MyLogon is also compatible with Windows 2000 and to a limited degree with  NT4 Workstation,  allowing the same logon-applet to used on both new and legacy computers. Windows 7 compatibility is planned for Version 3.