The Mole 39: Technical Answers from Inside Microsoft - Locked Files, Securing Exchange, Batch File, NT Shutdown, BackTalk
August 10, 2000
Editors Note The questions and answers below are from the Inside Microsoft column that appears regularly on the TechNet Web site at the following location: https://www.microsoft.com/technet/community/columns/insider/default.mspx. To find out how to submit questions of your own, see the end of this article or go to https://www.microsoft.com/technet/community/columns/insider/default.mspx.
The TechNet Mole provides expert answers from deep within Microsoft to questions from IT professionals. This installment focuses on these issues:
Two-fer 1: Who or What Has Files Open?
Two-fer 2: InUse Is Good But...
Secure Communicating with Exchange
A Trip Down Memory Lane
Power Down after Shutdown on NT 4.0
BackTalk:
One IT Pro's Experiences with Scripting Installations and Pats on the (furry) back for Mole and TechNet
Mole Recants!
On This Page
Two-fer 1: Who or What Has Files Open?
Two-fer 2: InUse Is Good But...
Secure Communicating with Exchange
A Trip Down Memory Lane
Power Down after Shutdown on NT 4.0
BackTalk
Credits
Two-fer 1: Who or What Has Files Open?
Dear Mole,
We are having a problem with files getting locked in a WinNT 4.0 environment. We check to see if something looks out of place but do not find anything. The only way we have found to get rid of the locks is to reboot. Is there a way to look at a file and see what processes are accessing it?
John Saxon, Paragon Product Support
... and this, from Greg Obleshchuk:
Two-fer 2: InUse Is Good But...
I do a lot of COM+ programming in VB and constantly have the problem of locked DLL. I shut down most of my services before I can replace the file. The in-use programs will replace locked files but I can do this after a reboot , I need some way of finding the program that has the DLL locked. Can you help? (no one else seems to be able to help.)
Greg
Well, now, John and Greg,
You know, sometimes Mole receives similar questions from different people simultaneously—a two-fer, or three-fer, or—well, you get the idea. Mole assumes that you two IT Pros don't know each other and that you're not trying to tip the scales in favor of your letter being aired by submitting the same question more than once. Rather, he views it as merely a smallish sample size and he extrapolates that others perhaps have the same issue.
As often happens, if the NT administrator wants to do something that is not provided for in the normal GUI tools that come with NT, the first place they should turn to is the NT Resource Kits--NT 4.0 Server ResKit and NT 4.0 Workstation ResKit. However, the ResKits do not provide for every imaginable, every possible, every never-before-thought-of problem, encounter, or quirk. So if you don't find the utility you're looking for in the ResKits, your next step should be the SYSINTERNALS website (https://www.sysinternals.com/). There is just a TON of great utilities there–many that won't cost you a dime. Even the Mole refers to Sysinternals from time to time (What? You thought perhaps Mole keeps all this information in his head?). Once again, this is where he going to send you.
Mole is happy to provide not only a reference to a utility that has a GUI interface, but also a reference to a Non-GUI utility for those who prefer that their interaction with the computer take place in a textual world. Both are available, at no extra cost, and are available from the Sysinternals website.
First the non-GUI tool, called Handle for Windows NT. Handle is a utility that displays information about open handles for any process in the system. You can use it to see the programs that have a file open, or to see the object types and names of all program handles. Very cool.
The other utility is the GUI driven version, called "HandleEx." Here's a blurb describing HandleEx's features:
HandleEx is a GUI/device driver combination that together show you information about which handles and DLLs processes have opened or loaded. Its display consists of two sub-windows. The top always shows a list of the currently active processes, including the names of their owning accounts, whereas the information displayed in the bottom window depends on the mode that HandleEx is in: if it is in handle mode you'll see the handles that the process selected in the top window has opened; if it is in DLL mode you'll see the DLLs and memory-mapped files that the process has loaded. HandleEx also has a powerful search capability that will quickly show you which processes have particular handles opened or DLLs loaded.
Get HandleEx at https://www.sysinternals.com/ntw2k/freeware/procexp.shtml.
Now, be on your way, John and Greg. Find out what app has your files open!
Handily yours,
Mole
Secure Communicating with Exchange
Mole,
This one is in regards to SSL and MS Exchange server. Please confirm or deny this rumor for me...
I have been informed (by the maker of a POP3 e-mail client for PDAs) that when any mail client wishes to send (SMTP) mail using SSL with an MS Exchange Server (let's say ver. 5.5 rather than 2000), the client & server first perform a CLEAR TEXT AUTHENTICATION before beginning the SSL session.
I had thought that with SSL, certificates would be passed before log on credentials get passed. If my ID & Password get sent in Clear Text before the SSL smokescreen goes up, I don't feel very secure at all!
What is the Real Deal? Are my credentials safe or not?
Rick Roberts, Special Projects Analyst, Davis Wright Tremaine, LLP
Breathe easy, Rick,
Your safety is assured. When Mole presented this question to his sometimes-malevolent neighbor, the Cornered Badger, to get a second opinion. The curmudgeonly C.B. responded, "What would be the point of using SSL at all if the most important piece of information isn't encrypted?"
Okay. Sounds logical. Mole will liaise on your behalf since C.B. seems a little overly testy today. Here is the gist of our discussion.
The SSL session is most definitely established before authentication with the Exchange Server takes place.
Microsoft Exchange Server versions 5.0 and 5.5 support a variety of Internet-focused protocols, including POP3, HTTP, LDAP, and NNTP.
POP3 allows for multiple types of user authentication. These can be configured using the Authentication Property Page on the POP3 object located in the Exchange Server Administrator program under Protocols. Specifically, three types of authentication can be used: Basic (Clear Text), Windows NT Challenge/Response, and Secure Sockets Layer (SSL).
The Secure Sockets Layer (SSL) authentication method uses public/private key technology to ensure privacy. The SSL protocol, which resides at the OSI presentation layer, moves data from the application layer to the TCP transport layer, which is responsible for authentication, encryption, and verification of data integrity.
The authentication function ensures that data are being sent to the correct server and that the server is secure. Encryption ensures that data cannot be read by anyone other than the target server. Data integrity ensures the data have not been corrupted or altered in transit. All client/server communication occurs on an SSL-encrypted channel on port 995.
Here are the basic steps that take place:
The client obtains the server certificate.
The client verifies the server.
The client and server determine the encryption key to use for this session.
The data is encrypted with the agreed-upon key.
Want more details? Then take a look at Knowledge Base article **175440:**Protocol Authentication on Exchange Server.
Here's another tidbit free from Mole. When you try to make a Secure Socket Layer (SSL) connection to an Exchange Server 5.0 or 5.5 computer through POP3, IMAP4, LDAP, SMTP, or NNTP, the following pop-up error message may be displayed on the mail client:
The server you are connected to is using a security certificate that does not match its Internet address, do you want to continue using this server?
YES or NO
More information, including the cause and workaround can be found in Knowledge Base article **198564:**Internet Security for POP3, IMAP4, LDAP, SMTP, & NNTP.
There you go, Rick. Brew yourself a cup of herbal tea and sleep well.
Securely yours,
Mole
A Trip Down Memory Lane
Dear Mole,
I was hoping that you might be able to help me out. I want to create a batch file to add a domain global group to the local power user group on all my systems in my domain. I have been unable to find the executable that will allow me to do this. I know that there is a command that will do this for me. Can you let me know which one it is? I would appreciate the assistance.
Robert Parson, Systems Administrator
You are in luck, Robert,
There is indeed a secret command to do this. And Mole is licensed to divulge it. Actually, Mole exaggerates, the command is not so secret. It has been around since the olden days–or least part of the command has been around since the LanMan days. (Ah yes, I remember them well...)
For those of you who are chronologically challenged (or just plain forgetful), LanMan (short for Lan Manager) was a network operating system that preceded Windows NT and ran on OS/2. This was back in the days when the network operating system was not incorporated into the operating system.
The command Mole suggests is an extension of the "NET" commands. In the LanMan days (version 2.0c and earlier), you needed to include such commands as "net use x: \\server\sharename" in your autoexec.bat file to reestablish connections to shares between reboots. As of LanMan version 2.1, there's no longer any need to use the NET USE command to reestablish connections since the persistent connections feature was added to version 2.1 and has been in NT ever since. Yaayy!!!
OK, Robert, this is what Mole suggests. Use the NET LOCALGROUP command to add the Global Group to your system's Local Group. Here's the syntax (obtained by entering NET LOCALGROUP /? At the command prompt):
NET LOCALGROUP [groupname [/COMMENT:"text"]] [/DOMAIN]
groupname {/ADD [/COMMENT:"text"] | /DELETE} [/DOMAIN]
groupname name [...] {/ADD | /DELETE} [/DOMAIN]
So, let's assume that you're logged on as a local administrator on the computer to which you want to add the Global group to the local Power Users group. You could execute the following command from the command prompt.
NET LOCALGROUP "POWER USERS" "MYDOMAIN\Global Group Name" /ADD
Note that you need to enclose the group name within quotes if the group name has spaces in it. You can slip this command in your batch file, but know that the command must be executed under the context of an account on the local machine that has the privilege to modify local groups.
Have fun, Robert.
Mole
Power Down after Shutdown on NT 4.0
Hi,
The Mole says that this feature is built into W2000. I have a dual boot Packard Bell box with W98 & Professional & Server. Auto shutdown does NOT work. I can't find any info on how to enable it! Can you help?
Mike.
Mike,
Of course Mole can help. First, two things need to be in place:
A correctly configured registry setting
The systems' BIOS *must* support Power down after shutdown.
More information can be found at the end of this week's column, under the (sigh) "Mole Recants!" title.
Yours,
Mole
BackTalk
One IT Pro's Experiences with Scripting Installations and Pats on the (furry) back for Mole and TechNet
The Mole 15: Scripting Remote, Silent Patch Installation in NTW
Browsing through TechNet, I noticed the Mole column from August 16. I read it with interest because it looks very similar to what I have developed at the University of Waikato Library.
I have developed an unattended installation wrapper for our NT installs which includes starting the scheduler service and adding C:\Winnt\schedule.cmd to run once a week with the 'at' command (the registry is also modified at installation so that the scheduler starts automatically on boot). This schedule.cmd script checks a server share for another script (that is edited on the server of course). The scheduled script can also be run manually or scheduled for other times as required.
We have machines in different configurations in the Library, i.e. they have different software installed etc. The name of the server script that is runs depends on the existence of certain files in the root directory of the boot disk. In turn the server script is written in such a way as to check for the existence of various key files/directories to control flow of execution, for example these files may indicate what department the machine is in. All commands/installers we use are written to be silent. I have also noted that the server script has to be silent which includes sending nothing to STDOUT. If this happens the script halts, I believe this is because the system account does not have an STDOUT. To check the successful completion of each task in the update script, command output where required is appended to a log file (also on the server). In this way our team can keep track of which machines have run the update and which tasks each machine has completed.
Using the scheduler service in this way has enabled us to update NT service packs or virus definitions, synchronize time with servers, install and update MS Office 97, and other apps remotely and silently. It has been so successful that the Library uses it as a tool for deploying all major software updates and changes to machine configurations. I note the caution of the Mole to test and to this I would agree wholeheartedly. As I have found out the hard way, improperly tested scripts/changes can wreak havoc on a sickening scale, but done properly it is a straightforward exercise for a very small team of consultants (two) to administer approximately 200 NT workstations and keep them up to date.
I would also like to put in a plug for documentation of scriptable tasks under NT. As a frequent TechNet user with the above situation to administer I am always looking for automated ways of doing things. To date I have found out much of the knowledge necessary to accomplish this task from TechNet, but I suspect that there is a lot more knowledge that can be made available to assist with my work.
BTW Mole: It was well worth the time spent setting it up. I don't think that there is anything macho about it. I prefer "think smarter not harder."
Regards,
"matich1" from New Zealand
Dear "Matich1,"
Sorry for not using your real name, but Mole didn't see it in your letter. Be that as it may, Mole would like to say that he appreciates the confirmation about testing, but even more, he appreciates you taking the time to describe your experiences with scripting your installations. A big thanks to you and your staff!
Mole Recants!
Forgive me, dear readers, Mole has slipped up. (Can you believe that?) In the last column, he said that it was not possible to have NT 4.0 "auto-power shutdown." That's when you click Start, Shut Down, Shut Down Computer and the computer actually shuts ALL the way down—powering off.
Well, turns out it is possible. Here is the scoop:
There is a registry setting that should do the trick. Setting the REG_SZ value to "1" enables this feature... IF it is supported in the system's BIOS .
Here is the registry key:
HKLM\Software\Microsoft\Windows NT\CurrentVersion\Winlogon\PowerDownAfterShutdown:REG_SZ:1
Setting the REG_SZ value to 1 enables the auto power down. If you enable the PowerDownAfterShutdown option in the registry, clicking Shut Down The Computer on the Shut Down menu automatically powers down the computer when Windows NT is finished shutting down (if this feature is supported by the computer's BIOS).
More information can be had from Knowledge Base article **155117:**Shutdown And Power Off Does Not Appear on Shut Down Menu.
Thanks to all who pointed out that Mole tripped—the eagle-eyed Greg M., Ernst, and Mike B., among others.
Humbly yours,
Mole
Credits
Mole wishes to thank the fascinating and talented Lon Collins for his input.