Hiding a DC Made Easier
Gil Kirkpatrick's "Authentication Topology" (March 2003, http://www.winnetmag.com, InstantDoc ID 37935) was a great article. I am planning to use the ability to hide a domain controller (DC) from everyone (except for replication with the globally unique identifier—GUID—CNAME) to implement a replication site for disaster recovery. The article came in very handy.
—Jesse Sutela
jesse.sutela@hp.com
Looking Out for the Little Guys
Although I get a little tired of Microsoft bashing, I read Letters to the Editor: "The Soul of Windows" (March 2003, http://www.winnetmag.com, InstantDoc ID 37952) and I couldn't agree more with what reader Thomas S. Fortner had to say about Microsoft's prevailing attitude regarding features and sizing. The company constantly bashes customers with the marketing hype that supposedly targets small businesses, but its product feature set often "oversizes" the requirements of small organizations, over-complicating their designs and permitting security flaws and holes to creep in.
I'm in a small IT shop that provides support for small to midsized businesses by using the Microsoft Small Business Server (SBS) platform for many clients. We've fought feature overkill and strived to keep tight, secure networks. We've recently been shopping for Linux- and UNIX-savvy technicians to give clients an alternative to the Microsoft platform. Although I only dabble with Linux, I've found both the regimented structure and the ability to plug in features only when necessary to be elements of a provocative and desirable philosophy. (For example, an OS in the warehouse might exclude a Web browser to ensure that users limit Internet access to email only.)
Although the cozy days of free OSs on disk for curious technical conference attendees might be over, I think a return to that "cult" mentality might be a positive move for Microsoft. The folks at Redmond must balance their view of software for the masses against that of software in the enterprise and come back to concentrate on the market segment that made the company what it is today.
—Rich Lambert
richardl@starshiponline.net
Field Notes About KVM over IP
I realize that Ed Roth's "KVM over IP Solutions" (February 2003, http://www.winnetmag.com, InstantDoc ID 37595) was meant to only skim the surface, but because I've been a user of Avocent's DS1800 almost since the product came out, I thought your readers might like to know the following:
- Keyboard/video/mouse (KVM) over IP solutions are useful for documenting the undocumentable: Because you're dealing with the KVM signal and no software is required on the server, you can easily document screen shots of blue screens, for example, to include in your crash reports.
- Although the DS1800 is great at scaling up, be careful when you connect existing compatible regular KVM switches. For example, if you hook up an eight-port KVM switch to a DS1800 port, only one system on any of these ports will be available at one time. You can't share the port that's cascaded down to a regular KVM switch (although the price of these switches is probably about 15 percent of the price of KVM over IP, so regular KVM switches might still constitute a worthwhile compromise). The result will be a slightly confusing message that another user is already connected to this server, although the user is in fact connected to a different server on the same switch.
- This software requires quite a bit of bandwidth and is nowhere close to Terminal Services in terms of performance over low-bandwidth remote connections. I sometimes find the DS1800 difficult to use even over a high-speed VPN connection.
—Pierre Dumoulin
dumoulip@hotmail.com
Required Reading
Randy Franklin Smith's "Controlling User Account Logons" (February 2003, http://www.winnetmag.com, InstantDoc ID 37600) should be required reading for all IT administrators. I would urge one important addition to the policies Randy recommends: Prohibit any user from being logged on more than once. Prohibiting multiple logons removes the possibility of an intruder using an account while the authorized user is logged in and also quickly trains users that they need to log off when they leave one workstation and go to another, rather than leaving a logged-on workstation open to anyone. This practice also quickly gets users out of the habit of using any account other than their own or giving their account information to anyone else.
—Larry Heberlein
larryh@engagent.com
End of Article
Register
