However, once you start this operation you will face some security issues. To consolidate the domains, you'll probably want to copy existing user accounts from one Domain into another (unless you want to start from scratch). Even if you fully replicate a user account--EA has an account replicator tool that can do the job--you'll need to deal with Windows NT Security Identifiers (SIDs). To transfer ownership of the file from the original user in Domain A to the consolidated user in Domain B, for example, you'll need another tool that is bundled with EA. The File Security Translator tool copies the correct SID values into the security descriptor of all relevant files. It's a pretty handy feature, although when we used it, the replicator tool declared it had some warnings, without disclosing what they were. They did not show up in the event log either. Though annoying, it's a small bug for Mission Critical to address.
Of course, all your security measures will be useless if you do not have a way to audit major events. Tracking down what happened when and who was responsible is crucial to the success of any security policy. EA does its part to make sure that information is available to you. All significant events are tracked in the Event Log of the EA server. Significant events include actions on resources (both successful and unsuccessful), such as stopping a service and changing definitions of existing resources. EA also provides a reporting tool, written in MS Access, that offers 30 different reports detailing all system activity. If MS Access is not installed, EA installs an Access run-time engine. It is not Crystal Reports, but it covers a lot of ground. You'll be hard-pressed to find a report you really need that is not available. For example, we used Event Log Resource Change Summary, Security Definition Change Summary and Share Resource Change Summary, among many others. When dealing with thousands of users, as we were during our tests, a good reporting tool can be your best friend.
Experienced network administrators know that one day, when they least have the time to spare, they will need to perform a repetitive common task that applies to a large set of user accounts. EA attempts to automate repetitive processes, allowing administrators to perform time-consuming, error-prone tasks with just a few keystrokes. The Task Automation Scripting Kit (TASK) alongside the command-line interface (CLI) to EA creates a powerful combination that enables the administrator to perform actions that would otherwise take hours. For example, we had 500 users in a group called Badgers and another 1,200 users in a group called Packers. We used the following command to change the home directory field of all the users to point to another server:
EA USER @GroupUsers(Packers), @GroupUsers(Badgers) UPDATE HOMEDIR:\\SUPER\USERS\@Target()
EA automatically expanded @Target() to refer to the current user for whom the operation is being performed.
Our testing showed that EA does not consume a lot of system resources. We found its response time to be adequate, and it does not require a separate server; we ran it on the same server that contained our user accounts and home directories. It was also our Primary Domain Controller and was running Internet Information Server (IIS).
Midway through our testing, we yanked the network cable connecting our server to the network, making it basically a stand-alone machine. Doing this had no effect on the local operation of EA on the server; obviously, network-dependent operations were not available. To make things a bit worse, we reconfigured the NT server to have a DHCP-assigned IP address, but without having a DHCP server available. This is equivalent to messing up your IP addresses within the network. We couldn't use EA anymore, even to perform simple local tasks. Though not a critical issue, as Windows NT Server Manager quit working, too, Server Manager did not provide any indication of what the problem was. We can think of a couple of situations in which a network misconfiguration could occur and local access to EA would still be useful.
Master Design & Development Trusted Enterprise Manager v2.03
It's a little bit simpler to delegate NT rights and powers using TEM than it is with EA. In effect, TEM says, "Give me the names of the users you want to assign rights to and which rights to assign," and it takes care of the rest. When things work, they work nicely. But when they don't, you'll have the support-line phone number committed to memory in no time.
In our configuration, we set up our NT server with a FAT32 partition on its C:\ drive. (Windows NT cannot access FAT32 file systems.) Our installation went smoothly, and the program knew that it should install onto D:\ instead. However, once installed, the software attempted to write temporary files to hard-coded locations on the C:\ drive. Of course, the operation failed. After much correspondence with Master Design & Development, its technical staff agreed that it is not a permissions problem and found the problems while sifting through their source code. They promised a fix to this problem in the next release of TEM, version 3.04. When testing the install/uninstall procedures, we also ran into some problems with services. Master Design & Development will be working with Install Shield to revamp the installation process to make it better and smoother.
|
REPORTS
ANALYTICS
Follow 
