|
Appendix CTips and Tricks with NT ServerNo matter how much work you expend designing an outline for a guide, you always realize somewhere during the writing process that there is a better way to do things—so you must go with the flow. Originally, this appendix was called Ten Tips for Setting Up an NT Server, but when I got to writing it, I realized that all the good tips and trick on setting up an NT Server were covered in Chapter 4, Installing Windows NT Server. I realized it would be better to include an appendix for all those nifty little things that don't easily fall into a particular chapter, but make using and administering an NT Server easier and more pleasurable. That's what this appendix has become. 1. Deleting Files with Reserved NamesThere's nothing worse than running across a file on your system such as LPT1, PRN, or COM, and not being able to delete it. If you've never run into this problem, you might not even know it exists, so pay attention and you'll be able to fix it if it even happens to you. The problem is that there are certain reserved words that NT uses for addressing certain devices. It is possible to create an actual file using one of these names, but when you try to use any of the standard NT utilities to delete it, it can prove quite difficult.
The reserved filenames are as follows:
Most Windows NT utilities honor these device names and will not permit you to create a file with a reserved name. Let's take a look and see what happens when we use the command prompt to try working with a file that has a reserved filename. In this example I used a trick to create a file called com1 in the directory d:\users\default. In Figure A.1 I have brought up the command prompt and issued the dir command to display the directory. A directory showing the existence of a file with an invalid filename.
So what's so hard about deleting this file? Well, let's try to use the built-in command del to remove the file. The syntax we will use is del com1. Likewise, we could type del com1., or even del d:\users\default\com1 and we would get the same result. Figure A.2 shows what happens when you issue this command. Trying to use the del command to delete a file with an invalid filename.
As you can see, the del command is ineffective in removing the file. To satisfy your curiosity, you could also try using the commands erase, rename, and move to manipulate the file. However, you will find these utilities are equally ineffective. Likewise, the Windows GUI tools such as Explorer and File Manager are unable to delete these files. In fact, in the beta release of Windows NT 4.0, which I am currently using, if you click on a file that has a reserved name, the current Explorer window goes off to la-la land, never to return. I've been assured this will be fixed in the shipping product. So how do you delete these files? Actually there are three ways; one is the easiest and will always work. The other two have caveats. These three methods are as follows:
The first method takes advantage of a special direct naming convention that NT uses to bypass checking for reserved filenames. This convention is \\.\<drive letter>:\<path>\<filename>. For example, to delete the pesky file we created previously, we would type del \\.\d:\users\default\com1. Figure A.2 shows the result of this command. Figure A.3 HOLA Using a direct file addressing mechanism to delete files with invalid filenames.
As you can see, the del command did not return an error, and in fact the dir command shows us that the file was actually removed. To tell the truth, the way I created that file for this example was by issuing the command string copy con \\.\d:\users\default\com1 and then typing a few characters into the file. The second method mentioned previously for removing these pesky files is to take advantage of the POSIX subsystem. For those of you who don't really know much about the POSIX subsystem, there's not much to worry about. It is installed and enabled by default with Windows NT. The only problem is that the NT distribution CD-ROM does not include any POSIX commands. To get these commands, you need to install the Windows NT Resource Kit, which is available from Microsoft Press. The reason you can delete these files with the POSIX subsystem is because they are not considered reserved words. The concept of these being reserved words is a legacy of DOS and only provided for backward compatibility with older software applications. So how can you use POSIX to remove these files? The POSIX command rm is similar to the DOS command del or erase. If you have the Resource Kit installed, simply type rm com1 from the directory where the file resides and it will be deleted. Additionally you will find that all other POSIX utilities, such as mv, which is like the DOS command move, will work for manipulating files with reserved names. The third method of deleting these files is using a Macintosh client. For Macintosh computers, COM, AUX, LPT and the other names mentioned previously are not reserved words. This means that any Macintosh client can save a file called COM1, which is then inaccessible by Windows clients. In fact, this is the most common way that these annoying files get created. This is probably the most inconvenient way of deleting these files, but it is possible, should you need to. 2. Connecting to a Remote Machine as a Different UserSo what is this section all about? Well for me, one of the most annoying things about using Windows 3.x or Windows 95 is the inability to connect to different machine on the network using different user names. I've met many administrators who've never even tried this, but I find it invaluable and once you start doing it, you'll never want to stop. So why do it? Well, security for one, and convenience for another. In chapter 25, Advanced Security Guidelines, one of my recommendations is that you use a non-administrative user account for your day-to-day work at your workstation. The problem is, if you need to do a quick administrative task, you have to log out and back on, using another account, or you have to go to a different computer. If you come from a UNIX background where you could simply use SU to get administrative rights on the fly, the lack of a similar feature in NT can sometimes be a pain. So how does this all work and why doesn't it work with Windows 3.x or Windows 95? It's quite simple. Windows NT can keep track of a different set of user credentials for each server you connect to. Windows 3.x and Windows 95 do not have this capability. They try to use the same user name and password for connecting to all network devices. So what? When, exactly, would I want to do this? Well, first and foremost would be for your daily activities. Let's give you a scenario. I administer a bunch of machines, both NT Workstations and NT Servers. I administer these machines from my NT Workstation in my office. We run a reasonable amount of security, and as such, I use a nonprivileged account, jgarms, for my daily work. Now I need to make some administrative changes on an NT Server called ROME. Let's say I want to add a user. My administrative account is called jg-admin. So, I need to logon to ROME using the account jg-admin. There are two methods of doing this. The first, and most common, method is to establish a drive connection to the remote machine using the Connect As option. This is shown in Figure A.4. Connecting to a network drive using a different user account.
There are two disadvantages of this method. First, you might not want to connect to a share on the remote system. While connecting to a drive share achieves the purpose of establishing a user context between you and the remote system, it is unnecessary. Additionally, if persistent connections are enabled, you will have to disconnect from the drive when you are finished or the connection will be reestablished each time you logon. This is messy. Second, and probably more important, the Connect As option does not enable you to specify a different password. What will happen is that NT will try to connect to the remote system using the user name you entered into the connect as box, but it will send the password from your current user account. If the passwords for the two accounts are the same, the connection will succeed. However, if the passwords are different, it will fail and you will be prompted with a message to enter a correct user name and password, as shown in Figure A.5. You will receive a logon failure if the passwords don't match.
This can really be a problem when you are using the intruder lockout features of Windows NT. This connection failure is registered by the NT Server as a failed logon attempt, which could result in accidentally locking out your account. The cleanest method of establishing a session with a remote NT system using a different user context is to use the command line. This enables you to create a session—without establishing a drive share—which is all that is necessary. The command you want to use is net use \\<server name> /user:<domain name>\<user name> *, where <server name> is the name of the remote NT system you are connecting to, <domain name> is the name of the domain where the user account you are using comes from, and <user name> is the account you want to use to connect. The * tells NT to prompt you for the correct password. You can leave the domain name empty if the user account comes from the domain of which the system you are connecting to is a member. This might be confusing, so let me explain by continuing our example. I want to connect to the server ROME. ROME is a member of the domain SALES. If I want to connect to ROME using my account jg-admin, which is an account in domain SALES, I would type net use \\rome /user:jg-admin *. However, if the user account jg-admin does not exist in the domain SALES, but rather exists in the domain PROCUREMENT, which is trusted by SALES, I would type net use \\rome /user:procurement\jg-admin *. Notice, the difference between the two commands. Okay. So let's try this. First I'll type net use, just to show that there are currently no connections to ROME. Then I'll type net use \\rome /user:jg-admin * to create the connection to ROME. I'll be prompted for a password, which I'll enter. As I enter the password, nothing appears on the screen. Finally, I'll type net use one more time to confirm my connection to ROME. These transactions are shown in Figure A.6. NET USE can be used to create an Inter-Process Communication (IPC) link to a remote server.
Notice, the connection to ROME shows up as \\ROME\IPC$. IPC stands for Inter-Process Communication, and is the remote procedure call (RPC) channel used to talk between the two NT systems. Now, I can use the User Manager, Server Manager, Event Viewer, or any other administrative tools to remotely manage the server. Also, now that I have a channel between me and the remote server, I can open additional shared drive resources from it without having to reenter the user name and password. For example, because my current user context to ROME has administrative permissions, I can connect to the administrative share for ROME's drive C, as shown in Figure A.7. The administrative shares are created automatically.
Note that you can only have a single user context between you and a remote system. What this means is that because I am currently connected to ROME as the user jg-admin, if I try to simultaneously create a new connection to ROME using a different user account, say my JGARMS account, I will get an error message, as shown in Figure A.8. Trying to connect to a network server using multiple user accounts simultaneously results in an error message.
Now, when you are finished doing what you need to on the remote system, you can delete the IPC channel by using the command syntax net use \\<server name> /d, where <server name> is the name of the server connection you wish to disconnect from. In my example, I would type net use \\rome /d. When else does this come in handy? If you are using NT Workstation on your user's machine and you go out to help them, you can use it to get a connection to a secured resource without having to log them out. This can really come in handy. Another time it can be useful is if you have a number of domains in your organization and don't necessarily have trusts set up between them. I use it sometimes from a help desk. I get calls from users with NT Workstations and NT Servers that I don't have any connection to. Sometimes the easiest way to help them is to have them create a local user account for me with administrative capabilities. I then use the techniques described previously to connect using the account they created for me. When I'm finished, either they disable the account or delete it completely. Having this flexibility is quite a blessing. 3. What to Do if You Lose Your Administrative PasswordTough question. Many people think that because NT is "so secure," if you loose your administrator account's password, and you don't have any other accounts with administrative permissions, you're up the creek without a paddle. Actually this is not true. I've talked to many people who have reinstalled NT from scratch and lost all their data because they were somehow locked out of their system. You don't have to do this! I went through a lot of soul searching when I was deciding how to approach this topic. Essentially, I am describing a method of breaking into Windows NT. While it is normally considered bad taste by most people to provide detailed explanations of how to break into systems, I decided that this isn't the case here. This is not some procedure where someone can break into a system undetected over the network. Nor is it even a method of infiltrating NT without leaving a trace. While it is possible to set up scenarios where both of these tasks are possible, what I will describe in this scenario is a simple method of recovering important files from a system to which you have full physical access. Additionally, in the process of performing this procedure you will effectively destroy the system in order to get to data stored on the disk. So why are we doing this? Well, if all other methods of accessing your NT Server fail, you would use this as a last resort. I've had people forget the only administrative password to a system. Or, even worse, a disgruntled administrator leaves your company and changes all the administrative passwords. If you keep backups, that might be fine. However, in case there is data on the system that cannot be recovered from backup, you could use this method to recover the necessary data before restoring the rest of the system from backup.
While the steps for performing this procedure are relatively simple, many people don't realize it can be done, because it is not fully explained in Microsoft's NT documentation. You will need a copy of the NT distribution media. The example here assumes you have the NT Server CD-ROM and three accompanying setup disks. Here are the steps to perform this operation:
Granted, this procedure is messy, but sometimes you need to recover files that might be otherwise unrecoverable. It's actually a good thing that this procedure does destroy the system. This way, you can tell if your system has been infiltrated. Also, by breaking into a system using this method, you replace the system's unique identifier token, which identifies itself to other systems in the NT domain. This means that if someone can gain physical access to a machine on your network and uses this method to break into it, they cannot use that to leverage an assault on other machines in the domain. 4. Using the Run Option In the Windows 95 InterfaceI'm sure that by now you've played with the Start button down there on the bottom left of your screen. Have you noticed the Run command? It does basically the same thing as the Run command from the Program Manager in NT 3.x. Well, actually there are some other neat things you can do with it, courtesy of the Windows 95 user interface. Here's one example of why the Run command is useful: I run around to lots of NT systems, many of which aren't mine. Because people love to customize their interface beyond recognition, it is usually easier to know what the names of various programs are and use the Run command to bring them up when necessary. Here are the executable names for some useful programs that I use all the time:
There is no difference between this and the way you could use the Run command in the Program Manger under Windows NT 3.x. However, the Run command in NT 4.0 gives you an additional feature that makes navigating your system and the network easier. As nice as the Explorer is, occasionally it can be inconvenient. That's why it is always nice to know more than one way to access information. From the Run command, you can type the universal naming convention name (UNC) of a resource you want to open, and it will be opened. So what? Well, here are some examples. If you need to see what's one the floppy drive, how would you do it? Well one way would be to double-click on My Computer and double-click on the icon for drive A. Of course if you do this a lot, you might have a shortcut for drive A also. Well, the Run command gives you another way. I have lots of tricks like this up my sleeves and people always think it's so I can work faster and get more accomplished. Actually, I think it comes from the fact that I'm fundamentally lazy. I want to do as little as possible to achieve a desired result. I use this particular trick with the Run command all the time when I am typing and don't want to take my fingers from the keyboard to use the mouse. To get a directory of drive A, equivalent to using my computer as described previously, all I do is use Ctrl+Esc to get the Start menu. Then I press R, for Run The Run window pops up. Then I type a:\ in the Run window, and press Return, and up pops a window with the contents of drive A. Net savings? Oh, a second or two. But if you're like me, you have your screen cluttered with dozens of windows that would have to be minimized or moved to even find My Computer. So what else can you do? Well, anything with UNCs. If I want to access a shared resource from the network, I can type the path, and it pops up for me. For instance, if I want to access a shared directory called FIGURES from a server called ROME, I would do the following:
It's as simple as that. This is also very useful when you are connected to a machine over a slow link, such as a modem with RAS. If I were to use the Network Neighborhood icon to find my location, it might take a while, because lots of data will have to come over the slow link. However, if I know that I want to look in a particular directory on ROME, I could simply enter the full path into the Run command and gain quick access. You can also use it to access directories on your local computer, just like we did previously to access the local A drive. If I want to see what's in the directory C:\USERS\DEFAULT, the navigation could take a few moments using the Explorer interface. However, using the Run command, you would simply bring up the Run window, type C:\USERS\DEFAULT, and you're there. 5. Using the Command LineI've been using graphical user interface (GUI) systems for over ten years. They definitely have their place and I would never give them up. However, there are also times where a good command-line interface can complement the GUI in a strong way. In the previous section, I talked about using the Run command from the Start menu to quickly access Windows programs or network resources. What I'd like to talk about here is how to expand on this and use Windows NT's Command Prompt to make your NT experience richer and fuller. Setting the Command Prompt to Automatically StartThe way I usually set my account is to automatically start a minimized Command Prompt session when I log on. I accomplish this is by using the following steps:
The Startup folder now contains a Shortcut to the Command Prompt.
Now every time you logon to this machine, you will automatically get a command prompt. The problem is it gets annoying to have it pop up in your way every time. So, let's go ahead and make the Command Prompt pop up minimized so it will be there, without being in the way.
Using the Command PromptSo now that we've gone through all this trouble to have the Command Prompt start up all the time, what are we going to do with it? Well, one of the nice things about the Command Prompt is that it will usually respond, even when the rest of the system appears to be bogged down. This gives you a fairly sure-fire method of controlling your system. Because I tend to run my systems to their limit, it's nice to be able to regain control with relative ease. When you have a Command Prompt open, you can use the Alt+Tab keystroke to bring it to the foreground. Because NT is very responsive to Alt+Tab, this is usually possible, even in the worst-case scenarios. Once you have the Command Prompt in the foreground, you can take back control of your system. To make this most effective, you should install the utilities that come with the Windows NT Resource Kit. This provides a number of command-line utilities to work with. However, you can also use the Command Prompt as a place for launching your Windows applications by using the START command. I often use the START command to launch applications I need. Also, you can create batch jobs that do a number of these activities for you. For example, from the command line you would type start eventvwr to bring up the Event Viewer, or start srvmgr \\ROME to bring up the Server Manager focused on ROME. The syntax for the START command is START ["title"] [/Dpath] [/i] [/min] [/max] [/separate | /shared] [/low | /normal | /high | /realtime] [/wait] [/b] [command/program [parameters]] "title"—This is the title that will appear in the window's title bar. /Dpath—This is the switch tells NT to set the default directory for the program or command to path. /I—Normally when you use START, Windows NT uses the default passes the default environment variables to the new program. However, if you specify the /i switch, NT will pass the current environment variables instead. /min—This switch specifies that the new program should be started minimized. /max—This switch specifies that the new program should be started maximized. /separate—Indicates that a 16-bit Windows program should be run in a separate memory space. This option is ignored unless the specified application is 16-bit. /shared—Indicates that a 16-bit Windows program should be run in a shared memory space with other 16-bit Windows applications. This option is ignored unless the specified application is 16-bit. /low—Tells NT to set the applications priority level to IDLE. /normal—Tells NT to set the applications priority level to NORMAL. /high—Tells NT to set the applications priority level to HIGH. /realtime—Tells NT to set the applications priority level to REALTIME. You should use the REALTIME priority class with care, because it can cause the rest of your system, including responsiveness to the keyboard console interface, to grind to a halt. /wait—Normally, an application that is launched with the START command is spawned off on its own and control is returned immediately to the Command Prompt. If you specify the /wait switch, the Command Prompt will wait for the spawned application to terminate before returning control. This is useful in batch jobs where the execution of subsequent pieces of the batch file depends on first completing a preceding event. /b—When you use the START command to start applications that run in the character-based subsystem, NT spawns a new Command Prompt window in which to run the application. If you specify the /b option, however, a new windows will not be created. Instead, the application will run in the existing window. Additionally, Ctrl+C handling is ignored. You must use Ctrl+Break to interrupt the application and return to the Command Prompt. command/program—This is the name (and path, if necessary) of the program you want to start. If the program runs in the character-based subsystem, a new window is spawned, and will disappear when the program is terminated. If you use START to run a command built into CMD.EXE, however, such as dir, or copy, the window will remain when the command is terminated. parameters—You can specify parameters to pass to the program So what else can we do from the Command Prompt? Lot's of things. 6. Using Nifty Features of the QuickView AppletHave you ever used the QuickView applet? This is one of those nifty little utilities that came to Windows NT along with the Windows 95 user interface. QuickView is a fairly straight-forward program that is useful for viewing text documents, Word documents, and other kinds of files. There is more to this little application than meets the eye, however. QuickView includes filters that enable you to view applications, Dynamic Link Libraries (DLLDLLs), drives, and other forms of executable code. If you've ever tried to use a text editor to view an executable file and have seen how messy and unintelligible they can be, you might be asking yourself "so what?" Well, one of the standard filters included with QuickView is able to read and decode these binary files and give us useful information that can be used for troubleshooting or to just to help get a better understanding of how things work. First, let's take a quick look at how to access the QuickView applet. The QuickView application and support files is located in the %systemroot%\system32\viewers folder. There is, however, an easier way to access it. QuickView got its name because it was created to fill two niches. First, it is quick and handy. This means that Microsoft created an easy and quick method of getting to QuickView. Second, QuickView was designed for its quickness—meaning that it is quick to load, so you can get a quick idea of what the file is before possibly loading it with an application such as Microsoft Word, which is not always quick to load. You can access QuickView from the Windows Explorer interface by right clicking on a file. This brings up the context-sensitive options menu. If QuickView has an installed viewer for the file type you clicked on, the QuickView option will appear, as shown in Figure A.16. You can open a file with QuickView by right-clicking on a file compatible with QuickView's installed viewers.
Now that we know how to get to QuickView, what good is it? Well, to be quite honest, it's not one of those applications that you will use everyday and change the course of your life. However, it has it's time and it's place. Let's take a look at an executable file using QuickView.
You can use QuickView to display internal information about an executable, such as CACLS.EXE.
Don't be intimidated by the things you see in this file. Let's just take a look at some of the things that are interesting to the average administrator.
To see some of the differences in information displayed, take a look at a 32-bit Windows program, such as the Notepad. For comparison, look at a 16-bit Windows program, such as Write. Yes, Write is still 16-bit and viewing it with QuickView will prove it! Also try viewing aDLL, a device driver, and even an MS-DOS program. If you have the Windows NT Resource Kit installed, try looking at one of the POSIX applications to see how it differs. Each type of file has slightly different information. Don't expect to understand it all at once, but comparing these files with QuickView could help you to get a better understanding of what's really going on inside these binary files. 7. Ownership of Files as an Administrative UserRemember that discrete ownership of an object is one of the foundations of NT's security model. Under this model, every single object has an owner. Under normal circumstances, the owner of an object is almost always a user. However, if the user is an administrator, the owner of the object becomes the local administrator. This concept is important to understand, because if you don't, it can seem as if NT is doing something wrong. So why does NT assign the ownership of an object to the administrators group instead of the individual administrative account? Well, the basic reason is that they expect that the administrators of a local computer will work together and granting them joint ownership makes that easier. Of course, the more complex reason has to do with the user's access token. When you take ownership of an object (or create an object), the system assigns a security identifier (SID) based on the value of the TOKEN_OWNER in the user's security token, which is assigned during the logon process. For normal users, the TOKEN_OWNER field identifies the user by using the user's SID. The exception to this rule is when the user is a member of the Administrators group. If this is the case, the TOKEN_OWNER field is set to the Administrator's SID. Windows NT does not provide a user interface that enables an administrator to take ownership of an object and set the new ownership to the user's SID, rather than the Administrator's SID. This is another reason why it is good practice to use non-privileged accounts for your daily work. So what does this mean in the real world and how does it look? Let's look at an example. I am currently logged on my system using a user account JGARMS. This account is a member of the local Administrators group. I just created a blank text document, called blank.txt, in the directory e:\users\JGARMS, as shown in Figure A.20. BLANK.TXT was created in E:\JGARMS\DEFAULT by the administrative user account JGARMS.
Let's look at the owner on that file. Right-click on blank.txt and choose Properties. Click the Security tab, and then on the Ownership button. This brings up the ownership information, as shown in Figure A.21. The ownership information confirms that this file is owned by the Administrators group.
If you try to take ownership of the file to see if the ownership can be set to the user's account, rather than to the Administrators group, you will discover that it doesn't work. Now, for the sake of understanding this better, I've removed the user account JGARMS from the Administrators group, logged off, and logged back on. Now, if I take ownership of the file using the exact same procedures as shown previously, the owner of the account will be JGARMS, as shown in Figure A.22. The owner of the file is now JGARMS, not Administrators.
As you can see, the owner of the file reflects the actual user, JGARMS, rather than the Administrators group. 8. Using OLE Properties to Identify Files Without ExtensionsIf you are familiar with the Windows 3.1x Program Manager-style interface, you are probably acquainted with the way File Manager uses a file's extension to determine to what program it is linked. For example, if a file has the extension TXT, by default it is opened with Notepad. Likewise, DOC files are opened with Microsoft Word (if you have Word installed). However, this mapping of extensions to applications is neither consistent nor reliable. After all, what happens if the extension is removed, or if you have multiple programs that use the same three-character extension? Well, the Explorer in Windows NT 4.0 inherits a useful feature from the Windows 95 interface. This interface tries to take full advantage of the OLE properties of a document to provide as much useful information as possible. Of course, this only applies to documents created by programs that save their documents as OLE containers, such as the Office 95 applications. To see what this is all about, let's take a look at an OLE document. Figure A.23 shows a PowerPoint 95 document created by someone at Microsoft, which I downloaded from their Internet site. DECUS.PPT is a PowerPoint 95 document from the Microsoft Internet site.
If we right-click on this document and choose Properties, the Properties window will appear as shown in Figure A.24. The Properties window for DECUS.PPT.
Notice that this Properties window includes tabs for the normal items you would expect, such as General and Security. It also includes tabs for Summary, Statistics, Contents, and Custom. These tabs come from the OLE properties of this document. If you've ever used an application from the Microsoft Office suite, you'll recognize the items listed under the Summary tab, as shown in Figure A.25. The entries in the Summary tab for DECUS.PPT are taken from the OLE properties embedded in the document.
As you can see, the summary information contains the title, subject, author, and other information about the document. We can even tell what file was used as the template for creating it. From the Statistics tab, we can find out information such as when the document was created, modified, accessed, and last printed. This information is included internal to the document as an OLE property. It is completely independent of the file system date information. The Statistics tab for DECUS.PPT is shown in Figure A.26. The Statistics tab shows information about the time the file was created, modified, accessed, and printed.
Different document types contain different information in the Statistics tab. For example, a Word 95 document gives information on the number of characters, lines, paragraphs, sections, and pages. The Contents tab also contains some useful information about the document. For example, in a PowerPoint slide, it contains information such as what fonts are used in the document, what template was used, and the names of all the slides. In addition, it lists any embedded OLE servers, such as clip art, Word documents, Excel spreadsheets, and so on. Figure A.27 shows the Contents tab for the DECUS.PPT document. The Contents tabs shows information on font usage, document template, and slide titles.
The Custom tab enables you to customize the type of information you want to gather by entering custom OLE properties. OLE Documents without ExtensionsSo, as you've seen, the OLE properties of a file can be useful for gathering information from a file, such as statistics, contents, and summary information. However, there is one more interesting thing that these OLE properties enable you to do with the Windows 95-style interface. Rather than explain it, let's take our example and I'll show you. We know that in the traditional Windows environment, the file extension, in this case PPT, is what identifies the program that should be used to open the file. PPT means PowerPoint. As we mentioned previously, this can be quite inconvenient, because some programs use the same extension as other programs, thus confusing things. Well, the Windows 95 user interface, which NT inherited in NT 4.0, tries to improve on the methods used to identify documents. It does this by accessing this OLE property information we were just talking about. However, it retains the support for document extensions for backward compatibility. So let's take a look at what this means. We'll use the DECUS.PPT document to demonstrate. DECUS.PPT is shown in Figure A.28. DECUS.PPT is a PowerPoint 95 document that will be used to demonstrate extracting information from OLE properties.
Notice that the Type listed for DECUS.PPT is Microsoft PowerPoint Presentation. If I didn't have Office 95 installed, or if it was installed incorrectly, the Type would be displayed as PPT Document. However, because I have Office 95 installed, I can double-click the DECUS.PPT icon and PowerPoint will load and open the document. This is normal and to be expected; there is no trickery involved. The Explorer simply reads the PPT extension and knows to open PowerPoint. So what? Well, I agree there is nothing special yet. However, what happens if we rename the document and remove the extension, as shown in Figure A.29. When you remove the extension from DECUS.PPT, the icon reverts to a plain file icon.
Note that the Type is now listed simply as File and the icon has changed to the simple file icon. However, if we right-click on DECUS, and choose Properties, we can still see the OLE information, such as Summary, Statistics, and Contents. Now, let's double-click on DECUS. If you're not trying this yourself, you'll have to take my word that PowerPoint opens up and loads DECUS. So how does this happen without a file extension? OLE magic. Now take note that this only works with applications that embed OLE properties into their documents. If you took an old Office document, such as a Word 6 file, stripped off the extension and double-clicked it, Word would not automatically load. This is because it is with Office 95 that began including all the OLE information necessary to make this magic work. While this might just seem like a cute feature for now, OLE properties represent ultimate doom for those inconvenient three-character file extensions. Now that we have long filename support in Windows 95 and on all file systems in Windows NT, and as more and more vendors begin to include OLE properties in their documents, it shouldn't be long before the often-confusing extensions go the way of the dodo bird. 9. Connecting to Machines Using Their TCP/IP DNS NameWhat is the Internet? No this is not one of those cheap riddles. The answer is really quite important. The Internet represents the ultimate wide-area network (WAN). This has been obvious to some people for quite some time, and believe it or not, Microsoft has been planning a lot more than some people realize. In the winter of 1995, people complained that Microsoft was missing the game when it came to the Internet. In a burst of thunder that shook the very foundation of Redmond, Microsoft announced their Internet strategies that caused reverberating waves throughout their entire product line. Well, actually, the game they were missing was the World Wide Web craze. While it was important for Microsoft to stake their claim in this race, they had really been preparing for other strategies on the Internet for many years. As we discussed earlier in this guide, that is what led to Microsoft's deep commitment to a solid TCP/IP product on all their platforms, and what also led to the development of WINS and DHCP. It's also what leads us to this tip. So what is the tip, you ask? Actually, I think it's one of the most incredibly useful improvements made in NT 4.0. It's the capability to connect to a network resource based on its TCP/IP DNS name—regardless of its location or NetBIOS/Windows name, and without WINS or LMHOSTS files. So what? Well this changes the nature of working over the Internet. I'll give you one good example and I think you'll appreciate it better. In fact, we'll use Microsoft's FTP server to demonstrate our point. If you want to download a file from Microsoft, how do you do it? Assuming you know what file you want, you might FTP to ftp.microsoft.com, navigate through the FTP site and grab what you want. This is okay, right? Well, actually, it's a little archaic. Even some of the shareware and commercial FTP utilities leave a bit to desire because FTP itself is the archaic factor here. How can we use some of the tools at our disposal to make this job easier? Well, one way, certainly, is to use a Web browser to locate and download the information. This is a compelling solution. But I want to show you one more. It's quite simple really, but very few people have tried it—get a standard Windows network connection to Microsoft's Internet site. We're going to bypass FTP altogether and use the built-in robust networking capabilities of NT to mount ftp.microsoft.com as we would any other network server. Of course this will only work if you are connected to the Internet, have TCP/IP installed, and have Windows Networking bound to TCP/IP. From the Start menu, choose Run and type \\ftp.microsoft.com. Depending on the speed of your network, a window will soon appear, showing the contents of ftp.microsoft.com, as shown in Figure A.30. You can connect to ftp.microsoft.com using standard Windows Networking to treat it like any other server on your network.
From here you can double-click on the data directory to look inside, as shown in Figure A.31. Connecting to \\ftp.microsoft.com\data brings you to the same place as using FTP to connect to ftp.microsoft.com, except it has a better interface.
If you FTP to ftp.microsoft.com, you will end up in this directory. If you use FTP, however, you don't get all the neat features that come with Windows Networking. Like what, you might ask? Well, you can use Find to locate any file on ftp.microsoft.com. Or, you can create shortcuts to frequently-accessed locations on this server. Or, yet another useful thing would be to create a Briefcase on your local server and use this to automatically synchronize data from ftp.microsoft.com. Service Packs would be a good example of a useful application for this. The applications are limited only to the features of Windows Networking. So why else would you want to connect in this manner, instead of using the standard FTP approach? Well, in this example we are connecting to Microsoft's Internet site, but you are not limited to that. You can actually use this method to connect to any Windows machines attached to the Internet, provided they have Microsoft Networking bound to their TCP/IP stack. Another advantage is while FTP has no secure form of user authentication (FTP passes passwords in clear text over the network) connecting to an NT Server like this over the Internet uses NT's secure challenge authentication protocol (CHAP). Furthermore, you can automate connections to these remote servers using standard Windows scripting tools. Also, when you copy files using FTP, the file's creation time and date get lost. Using the Windows Networking approach, however, these are preserved. To get a better idea of a use for this, let's take a look at an application. Microsoft maintains their Software Library on ftp.microsoft.com. This Software Library contains patches, bug fixes, performance enhancements, and other utilities for all their applications and operating systems. There is an index file they use to record all files stored in the Software Library. The Software Library contains thousands of files in a single directory (2,148 files as of April 14, 1996). If you were to look in this directory over a slow network link, it would literally take all day. To solve this problem, and to let us know when Microsoft adds files to the Software Library, we can create a Shortcut to the Software Library's index file and put that Shortcut on our desktop. The universal naming convention (UNC) for the index file is \\ftp.microsoft.com\data\Softlib\index.txt. This file is shown in Figure A.32 INDEX.TXT contains an index of the files in Microsoft's online software library.
Because we are working with standard Windows networking, simply right-click the index.txt icon and drag it to the desktop. Let go of the right mouse button wherever you want the Shortcut to be, and a menu will pop up asking if you want to move the file, create a shortcut, copy the file, or cancel. Choose Create Shortcut Here. The Shortcut icon will appear, as shown in Figure A.33. "Shortcut to index.txt" is a shortcut that points to a file on ftp.microsoft.com over the Internet.
Now, whenever you want to check to see the most recent additions to Microsoft's Software Library, simply double-click this icon. NT will establish the networking connection completely in the background and display the file as shown in Figure A.34. The INDEX.TXT file shows all the files stored in Microsoft's online software library, with the most recent additions at the top of the list. More Technical Stuff about Using DNS NamesSo how does this all work, and what's so special about it? Well, I'll address the second half of the question first. You can actually do something similar to this with Windows for Workgroups (WfW) 3.11 and Windows 95, but there is a big difference. With Windows for Workgroups and Windows 95, you need to create an LMHOSTS file and you cannot actually use the TCP/IP DNS name to address the remote server. You would have to enter the NetBIOS name for the remote server and its static IP address into an LMHOSTS file on each workstation you wanted to connect to. The downside here is that Windows NetBIOS naming is not hierarchical, which could result in two machines on the Internet having the same names—something STS cannot account for. Additionally, the need to enter a static IP address in the LMHOSTS file on each client could result in a big problem if the IP address of the server changes. This new feature of NT 4.0 enables you to address a machine using its DNS name without accounting for it's NetBIOS name. This is important because I can have a machine with a NetBIOS name of jason, and you can have a machine with the NetBIOS name of jason somewhere else on the Internet. With the LMHOSTS file, we would have problems connecting, because a name must be unique. Under NT 4.0, your computer name and my computer name can both be jason, but as long as their fully qualified domain names (FQDN) are different, we don't have a problem. So my computer can be called jason.xyzcorp.com, and your computer can be jason.USACollege.edu and we can connect without a problem. Additionally, with traditional Windows naming, each computer can only have one name. For creating an extensible environment, this might not always be useful. However, because DNS enables you to alias multiple computer names to the same IP address, or host, you can give your system multiple names. Let's use NET USE to see how NT treats this network connection. Figure A.35 shows the output of the NET USE command. NET USE shows that the network connection is in fact made to \\ftp.microsoft.com.
There is a command included in the Windows NT Resource Kit for 3.51 called INET. INET is a substitute for the NET command that enables you to enter DNS names or IP addresses instead of NetBIOS names. For example, you could type INET USE ftp.microsoft.com to get a connection to Microsoft's FTP server. However, there is an enormous difference between the way INET works and the integrated DNS functionality in NT 4.0. INET actually worked by resolving the DNS name, or IP address to a particular computer, and then querying that computer for its NetBIOS name, such as you can do with the NBTSTAT command with the -A or -a switches. It would then create an entry for this computer in your LMHOSTS file and address the computer based on its NetBIOS name. If you issued a plain NET USE command, you would only see the NetBIOS name of the computer. However, the new DNS lookup functionality of NT 4.0 does not work in such a roundabout and limited way. SummaryThis appendix looked at some tips and trick for making more productive use of Windows NT. Some of these tips such as examining file information based on their OLE properties, and using QuickView to view internal application code information, permit us to get a better understanding of how and why Windows NT works the way it does. Other tricks such as recovering data on an NT Server when you loose the administrator's password, or deleting files with reserved names can help you recover from common problems that could have very painful answers. Some of the other tips in this section are just intended to make your administrative job simpler, such as making effective use of the Command Prompt and connecting to a remote NT system using a different user account.
|
