How can I restrict users in our Windows 2000 network to only one concurrent connection? I'd like a solution that I can implement on our Win2K server, without needing to configure individual workstations.

The good news is that you can use the Microsoft Windows 2000 Server Resource Kit's Con-Current Connection Limiter utility (cconnect.exe) to restrict concurrent user logons. The bad news is that the tool has a somewhat involved installation procedure. You must install cconnect.exe on each of your Win2K and Windows NT 4.0 Service Pack 4 (SP4) or later clients (the utility doesn't support pre-SP4 NT, Windows Me, or Windows 9x clients). Furthermore, to successfully run Cconnect, your NT clients must also run Microsoft Data Access Components (MDAC) 2.0, Windows Script Host (WSH), and Web-Based Enterprise Management (WBEM). And you must set up a Microsoft SQL Server 6.5 or later database in which cconnect.exe will store data.

Setting up Cconnect takes a bit of effort, but the rewards make the trouble worthwhile. This versatile utility includes several components, including logon and logoff VBScript scripts and batch files, a client-side executable and setup utility, an administrative console and setup utility, documentation, and other assorted files. The tool's features not only let you limit concurrent connections on a per-user basis but also let you list the computers and logon servers that users are logged on to, save the lists to a file for further examination, determine how many users are logged on to a domain controller (DC), force logoffs when users reach the concurrent-connections limit, identify an improper shutdown and lock the system so that only the most recent user can log back on, debug the tool, and write events concerning the tool's status to a specified server's event log.

Cconnect.exe includes the cconnect.adm file, which you can use in conjunction with Win2K Group Policy and NT 4.0 System Policy to configure the tool's settings. One of these settings is cconnect.exe's SQL Server connection information. You must use the .adm file to supply certain SQL Server logon credentials (i.e., your SQL Server system name and a SQL Server username and password) so that the utility can access the SQL Server database in which it stores information. (Optionally, you can enter this information in the registry or you can enter the information manually, as Figure 1 shows, the first time you run cconnect.exe on each client. For detailed information about installing, configuring, and administering cconnect.exe, refer to the cconnect.doc file, which resides along with the utility's other components in the resource kit CD-ROM's \apps\cconnect folder.)

End of Article




You must log on before posting a comment.

If you don't have a username & password, please register now.

Reader Comments

Sean: What would happen if we installed this and the SQL server was unavailable/offline ? Would users still get logged on or would a failure of the SQL server amount to a massive DOS ? TIA

Paul

I would also like to know the outcome if SQL server was offline.

paul

The outcome is a little less than desirable. If the client workstation were to suddenly reboot (for whatever reason) or the client can't access the SQL server, then the information stored in the database is not updated. Result: Panic. The user is unable to login again, even though he or she may not be logged in anywhere else, the SQL server data reports otherwise. Solution: Manually delete the offending data in the database ... there maybe a script for it .. but I haven't found one yet. I have heard of UserLock and ServerBoss, but they are both commercial software ..

mhkhan

Article Rating 4 out of 5