By Val Bakh
1. Vista
1.1. Boot architecture
Starting with Windows NT, all versions of Windows that are intended for business include built-in support for multiboot configurations. You can install multiple instances of Windows on the same computer and choose which instance to boot to when the computer starts. The multi-boot architecture of legacy versions of Windows is based on a text file named Boot.ini. To control the boot menu, you can edit the Boot.ini file in a text editor, such as Notepad.
Windows Vista and all subsequent versions of Windows use a different boot architecture. Instead of using Boot.ini, Windows Vista maintains information about the available operating systems and the corresponding hard disk partitions in a binary structure known as the Boot Configuration Data (BCD) store. The easiest way to configure a computer to multi-boot among multiple versions of Windows is to install all earlier versions first and install newer versions, such as Windows Vista, last because Windows Vista detects the existence of earlier versions of Windows and accommodates them by creating a special entry for them in its boot menu. If you select Earlier Version of Windows from the boot menu, control is passed to legacy startup code, which displays a secondary boot menu that is based on the entries listed in a Boot.ini file.
By default, the Windows Vista instance installed last is designated as the default operating system. You can use the Bcdedit command-line tool to fully manage the BCD store. Alternatively, if you need only to change the default entry in the primary boot menu, you can open System in Control Panel in any Windows Vista installation on the computer, click Advanced system settings, open the Advanced tab, click Settings in the Startup and Recovery area, and then select the appropriate item from the Default operating system drop-down list box.
Suppose your computer runs Windows XP and Windows Vista and is configured for dual boot. What if, for whatever reason, you need to reinstall Windows XP? Then you will no longer be able to boot to Windows Vista, because Windows XP will change the boot code. Of course, after reinstalling Windows XP, you can reinstall Windows Vista too, but is there an easier way? Perhaps you can use Bcdedit to recover the Windows Vista installation? The answer to the first question is yes; you do not need to reinstall Windows Vista, because there is an easier way. However, the answer to the second question is no; you cannot use Bcdedit to restore the dual-boot capability of your computer.
Why not? After all, Bcdedit can fully manage BCD: it can create a new BCD store from scratch or rebuild an existing BCD store. The trick is that there is nothing wrong with your BCD store; it has not been damaged. When you reinstalled Windows XP, only the boot code has been changed. To restore the dual-boot capability, you should use the Bootsect command-line tool. It is included in any standard Windows Vista installation DVD and is located in the \boot directory. So you should boot to Windows XP, insert a Windows Vista installation DVD, and run the following command from the command prompt: E:\boot\boosect /nt60 sys, where E is assumed to be the letter for the DVD drive. This command will switch the boot code on the system volume back to Windows Vista.
Because the Windows XP installation has only switched the boot code and left the original BCD store intact, no further action is required to restore the dual-boot capability.
1.2. Network boot floppy
Suppose you need to install Windows Vista on a brand new computer. How can you start the computer? An obvious answer is to boot it from a standard Windows Vista installation DVD. But what if you need to deploy Windows Vista to several new computers and the installation files are on a network share? With earlier versions of Windows, you could use a network boot floppy disk. But can you create one for Windows Vista? The answer is no. And it is not just because modern computers rarely come with a floppy disk drive. The problem is that network boot floppy disks are DOS-based and it is now increasingly more difficult to find DOS drivers for network interface cards (NICs). And most importantly, DOS is a 16-bit operating system, whereas the Setup.exe command that initiates the installation of Windows Vista is a 32-bit application and cannot run under DOS.
An obvious solution is to boot from a standard Windows Vista or Windows 7 installation DVD. That is, if you have one. And if you don’t? You can create a bootable CD with Windows Preinstallation Environment, or WinPE. WinPE is a 32-bit or 64-bit operating system with reduced functionality. WinPE can be loaded from removable media, such as a CD or USB flash drive (UFD), into RAM and run directly from RAM. You can use Windows Automated Installation Kit (WAIK) to create a general-purpose or custom version of WinPE and then use WinPE to initiate an installation of Windows Vista or a more recent version of Windows or to perform various management or maintenance tasks on an already installed instance of Windows.
1.3. Restricting the use of UFDs
In some companies, employees have access to sensitive information. As an IT administrator, how can you prevent the employees from copying something from their Windows Vista or Windows 7 computers to removable devices, such as USB flash drives (UFDs), and taking the company’s secrets elsewhere?
By default, standard users can install devices whose drivers are located in the local Driver Store and are digitally signed and whose installation proceeds automatically without any user interaction. UFDs fall into this category, and by default, standard users need only plug a UFD into a USB port to start using it.
To prevent your company’s employees from using UFDs, you should enable the Prevent installation of removable devices policy, which is located in the Computer Configuration\Policies\Administrative Templates\System\Device Installation\Device Installation Restrictions folder in the Group Policy object (GPO) namespace. This policy is computer-specific; therefore, you should configure it in a GPO that applies to the appropriate computers. For example, you can create an organizational unit (OU), move all appropriate computer accounts into the OU, and link the GPO to the OU.
Sounds pretty easy and straightforward, right? Well, not exactly. The snag is that the driver for a UFD is installed the first time a user connects the UFD to a computer. If someone has used a UFD on his or her computer at least once before you implement the restriction, the user will continue to be able to use that particular UFD, even though he or she will no longer be able to use other UFDs or removable devices. For the restriction to apply to a previously used UFD, you should configure additional policies that restrict read/write access to removable disks and other removable storage devices. These policies are located in the Computer Configuration\Policies\Administrative Templates\System\Removable Storage Access folder in the GPO namespace.
1.4. IPSec in Windows Vista
IPSec is a secure extension of the IP protocol. IPSec provides data integrity and encryption for network communications. In earlier versions of Windows, IPSec is implemented through Group Policy. In Windows Vista and more recent versions of Windows, IPSec can additionally be implemented through Windows Firewall.
Windows Firewall is a software component that filters network traffic on a computer in accordance with specified rules. In addition to supporting traditional inbound and outbound rules that define which connections are to be allowed and which are to be blocked, Windows Vista also supports connection security rules, which define computer and user authentication methods and IPSec policies to be applied to specified types of network traffic.
Thus, to implement IPSec in Windows Vista, you can create a Group Policy object (GPO) and configure either a firewall policy with the appropriate connection security rules or legacy IPSec policies. Firewall policies are located in the Computer Configuration\Policies\Windows Settings\Security Settings\Windows Firewall with Advanced Security folder in the GPO namespace, and legacy IPSec policies are located in the Computer Configuration\Policies\Windows Settings\Security Settings\IP Security Policies folder.
The important point to keep in mind is to avoid creating conflicting requirements. You should always implement IPSec through only one method: if you use connection security rules in Windows Firewall, you should not assign IPSec policies, and vice versa.
1.5. Sharing folders in Windows Vista
Suppose you, as an IT administrator, need to enable Windows Vista users to share folders on their computers. What does it take to share a folder in Windows Vista? Does a user need the Allow – Full Control NTFS permission for it? Or maybe it has to be the Allow – Full Control share permission?—The answer to both questions is no. NTFS permissions control only the level of access, such as the ability to read or write, and share permissions control over-the-network access to the folders that have already been shared.
Then what? Give all users full authority over their computers by making each user a member of the local Administrators group on his or her computer?—Usually, not such a good idea, especially if you want to limit the extent of the damage the users can inflict upon their computers. The only way to enable a non-administrator share folders on a Windows Vista computer is to make that user a member of the Power Users group. By default, this group has very limited authority. Its members can share folders and manage shares by using the Computer Management console or the Shared Folders console but cannot use the Sharing Wizard or advanced sharing.
And one more thing. Power Users cannot change any sharing options in Network and Sharing Center. So don’t forget to enable sharing for them first.
1.6. GPO loopback
Group Policy objects (GPOs) provide a convenient means for centralized management of large numbers of computers and users. GPOs contain two types of policies: computer-specific and user-specific. To apply a GPO, you should link the GPO to an Active Directory Domain Services (AD DS) site, domain, or organizational unit (OU) that contains the computers or users that you need to manage. It is, sort of, obvious that computer policies in a GPO apply to the computers targeted by the GPO and user policies apply to the users targeted by the GPO. But is it, really?—Not always. There are situations where you may need to implement user policies on only a specific subset of computers. In other words, you may need to configure user policies in GPOs that target computers rather than users.
A typical example is public computers, such as the ones in a library or Internet café. Usually, public computers must be configured differently than the computers that are assigned to individual users in the same organization. How can you implement user-specific policies, such as those that control desktop, appearance and Internet Explorer settings, so that they will apply to all users when the users work on the public computers but will not affect any users when they work on their respective individual computers?
Let’s take a look at how GPOs are usually applied. By default, when a computer is started, the computer-specific policies from all the GPOs that target the computer are applied, and when a user logs on, the user-specific policies from all the GPOs that target the user are applied. So, normally, only computer-specific policies can be applied to all users on a subset of computers, whereas user-specific policies apply to only a subset of users on all computers.
So what are you going to do if you are an IT administrator in a library, university, or another organization that maintains both domain member public computers and computers assigned to individual employees? In the Computer Configuration\Policies\Administrative Templates\System\Group Policy folder in the GPO namespace, there is a policy named User Group Policy loopback processing mode. This policy has two settings: Replace and Merge. If you enable this policy and set its value to Replace, when a user logs on to a public computer, user-specific policies will be applied from the GPOs that target the computer, not the user. When the same user logs on to a non-public computer, a different set of user-specific policies will be applied from the GPOs that target the user. If, instead, you set this policy value to Merge, user-specific policies will be applied both from the GPOs that target the user and from the GPOs that target the computer. If there are any conflicts, the user-specific policies from the GPOs that target the computer win.
1.7. Lockout
By default, the built-in Administrator account in Windows Vista is disabled. At the end of a typical manual installation, you have to create another administrative account for yourself. Thus, when you log on for the first time, your account is the only one that is presently enabled. However, the operating system does not prevent you from deleting your account while you are logged on. Once you have deleted your account and logged off, there are no user accounts left for you to get back in. You have locked yourself out. What should you do now? Can you correct your mistake without having to reinstall the operating system? Don’t worry. There still is a way of sneaking in through a back door.
If the computer is still a stand-alone, restart it, press F8, and boot into Safe Mode. The built-in Administrator account will be temporarily enabled. As long as you remember its password, the one that you assigned to it during the installation, you can log on and create a new administrative account. Alternatively, you can enable the built-in Administrator account permanently so that it will remain available when you restart the operating system normally.
If the computer has already been joined to a domain, don’t waste your time booting into Safe Mode. The built-in Administrator account will not be enabled, because it will not be the only administrative account. By default, the Domain Admins global group is automatically added to the local Administrators group when the computer is joined to a domain. Thus any domain administrator can log on to your computer. If you are not a domain administrator, you will have to go and find one.
1.8. Printing from MS-DOS
MS-DOS is a command-line-based legacy operating system. For most of us, it is a relic, ancient history. Even though a today’s IT administrator should be savvy in all kinds of command-line tools, very few of us remember all of the DOS rules of the game. What if you need to run a DOS-based legacy application on a Windows Vista computer? No problem; Vista still has the Command Prompt window, doesn’t it? But what if this application needs to print to a local USB printer? Oops…
DOS does not natively recognize USB ports or devices. You cannot simply specify the printer’s name in a print command or select the printer from a list of available printers by using the GUI as you can do in Windows applications. DOS applications can print only to the screen, to a file, or to a parallel or serial port that DOS recognizes. So what can you do? You need to capture a printer port, such as LPT1, and associate it with the printer. Because DOS does not support USB, you cannot reference the printer directly; however, you can reference shared printers on the network. First share the printer, and then map the share to a printer port by using a command similar to the following:
net use lpt1: \\computer_name\printer_share_name.
So you can use not only your local USB printer but any shared printer on your corporate or home network. But here is another snag: what if your computer is not connected to any network and is not even equipped with a NIC? Sounds a bit unusual for the 21st century? But then again, how many people do you know who would want to use a DOS-based application nowadays? So, what—another oops? Of course, not. You are an IT admin! And your bag o’tricks is always full. Just install a Microsoft Loopback Adapter and thereby simulate a network.
Preparing for a Microsoft certification exam?
Our Microsoft practice exams can help by testing your knowledge, providing references that help you learn and simulating the actual exam experience.