Research Paper 1 It 221

1. Why windows Server 2008 come in different versions? What is the significance of each version?
Each Windows Server 2008 R2 edition provides key functionality to support any size business and IT challenge. Use the information below to decide which edition best meets your business needs.
Windows Server 2008 R2 Datacenter Edition is optimized for your large-scale virtualization of workloads that require the highest levels of scalability, reliability, and availability to support large, mission-critical applications.
With unlimited virtualization use rights and a hypervisor-based virtualization technology, Windows Server 2008 R2 Datacenter provides both flexibility and cost savings. Windows Server 2008 R2 Datacenter also supports the memory and processing needs of large-scale, business-critical workloads such as ERP, databases, server consolidations, and custom and line-of-business applications.
Windows Server 2008 R2 Enterprise Edition provides you with high levels of system uptime and the scalability to support the growth of mission-critical applications. It also provides a cost-effective way to realize the benefits of virtualization.
Providing uninterrupted business services to employees, vendors, and partners around the clock has become a critical business factor for global businesses. Remote employees and international customers and partners need to have continuous access to systems and data. A disruption in services can result in diminished productivity and lost opportunities.
Windows Server 2008 R2 Standard is designed to increase the reliability and flexibility of your server infrastructure while helping save time and reduce costs. Powerful tools give you greater control over your servers and streamline configuration and management tasks.
Windows Server 2008 R2 Standard provides organizations with the ability to deliver rich web-based experiences efficiently and effectively, with improved administration and diagnostics, advanced development and application tools, and lower infrastructure costs.
Special Purpose Editions
Windows Web Server 2008 R2 Edition was designed to be used as a single purpose internet facing web server that delivers rock solid foundation of infrastructure capabilities. It is integrated with the newly re-architected IIS 7.0, ASP.NET, and the Microsoft .NET Framework. Windows Web Server 2008 R2 enables your organization to rapidly deploy webpages, websites, web applications, and web services.
Windows HPC Server 2008 R2 high Performance Computing (HPC) gives analysts, engineers, and scientists the computation resources they need to make better decisions, fuel product innovation, speed research and development, and accelerate time to market. Some examples of HPC usage include: decoding genomes, animating movies, analyzing financial risks, streamlining crash test simulations, modeling global climate solutions, computational fluid dynamics (CFD) and other highly complex problems.
Windows Server 2008 R2 for Itanium-Based Systems offers a foundation optimized for the most compute-intensive and critical business analytics and enterprise applications. Windows Server 2008 R2 for Itanium-Based Systems provides a fault-resistant platform suitable for high-end RISC/UNIX system replacement, floating-point intensive applications, and applications that share data extensively among processes.
Windows Server 2008 R2 Foundation provides you with a base to run most small-business applications. It’s an affordable platform for the core portfolio of IT capabilities, including file and print sharing, remote access and security. A simple and familiar Windows experience makes it easy for organizations to get up and running.
As the heart of a true local area network, Windows Server Foundation lets employees exchange data securely, without requiring email or Internet access.
Easy availability of skilled manpower, compatibility with most hardware devices, and the peace of mind gained from running a genuine Windows-based server help you achieve the highest return on investment.
2. What are the new features or enhancements made to Windows Server 2008? How is Windows Server 2008 different from Windows Server 2003?
Many features are updated - as security, IIS and RODC.
In security it enable outbound firewall as well as inbound, IIS 7 release, Read only Domain controllers.
1. Virtualization
2. Server Core provides the minimum installation required to carry out a specific server role, such as for a DHCP, DNS or print server.
3. Boot sequence is changed
4. Role-based installation or, services are known as role in it
5. Read Only Domain Controllers (RODC)
6. WDS (windows deployment services) instead of RIS in 2003 server
7. Network Access Protection Microsoft's system for ensuring that clients connecting to Server 2008 are patched, running a firewall and in compliance with corporate security policies.
8. Power Shell Microsoft's new command line shell and scripting language has proved popular with some server administrators.
9. IIS
10. Bit locker System drive encryption can be a sensible security measure for servers located in remote branch offices.
The main difference between 2003 and 2008 is Virtualization, management.
2008 has more inbuilt components and updated third party drivers.
Microsoft introduces new feature with 2k8 that is Hyper-V
Windows Server 2008 introduces Hyper-V (V for Virtualization) but only on 64bit versions. More and more companies are seeing this as a way of reducing hardware costs by running several 'virtual' servers on one physical machine. If you like this exciting technology, make sure that you buy an edition of Windows Server 2008 that includes Hyper-V, then launch the Server Manager, add Roles.
Windows Server 2008, formerly codenamed Longhorn, is no less than 45 times faster than its predecessor, Windows Server 2003, in terms of network transfer speeds. Now whatever the perspective is on Microsoft's last 32-bit server operating system, the fact of the matter is that faster transfer speeds for of up to 45 times is quite an evolution compared to Windows Server 2003. Back in June 2007, Microsoft commissioned a study to the Tally Group focused on the networking performances of its latest Windows client and server operating system, which ended up as the "Enhanced Network Performance with Microsoft Windows Vista and Windows Server 2008" whitepaper. The paper pointed to the fact that both Vista and Windows Server 2008 managed to offer "Dramatic network performance benefits".
3. Why 64-bit architecture an advantage?
Better parallel processing
A server that is using 32-bit architecture is limited to 32 CPUs. Improvements in parallel processing and bus architectures enable 64-bit environments to support as many as 64 processors and provide almost linear scalability with each additional processor.
Faster bus architecture
A 64-bit architecture provides more and wider general-purpose registers, which contribute to greater overall application speed. When there are more registers, there is less need to write persistent data to memory and then have to read it back just a few instructions later. Function calls are also faster in a 64-bit environment because as many as four arguments at a time can be passed in registers to a function.
More secure
A buffer overflow occurs when a data buffer is congested with more data than it is designed to handle. In 64-bit editions of Windows Server, the first parameters of a procedure call are passed in registers. As a result, it is less likely that the buffer will overflow, because the correct values have to be set up in registers and the variables and addresses have to be aligned on the stack.
The 64-bit processors made by AMD and Intel include hardware support for data execution prevention (DEP). Windows Server uses DEP to prevent malicious code from being able to execute, even when a buffer overrun occurs. Even without a processor that supports DEP, Windows Server can detect code that is running in memory locations where it should not be.
Microsoft Patch Guard technology prevents non-Microsoft programs from patching the Windows kernel. This technology prevents kernel mode drivers from extending or replacing kernel services, including system service dispatch tables, the interrupt descriptor table (IDT), and the global descriptor table (GDT). Third-party software is also prevented from allocating kernel stacks or patching any part of the kernel.
Better scalability
In a 64-bit environment, not only can database servers gain nearly unlimited virtual memory address space, but they also gain support for more physical memory. It is possible for a 64-bit server that is running 64-bit editions of Windows Server and SQL Server to get very large working data sets entirely into RAM, thereby improving performance and scalability. In addition, the number of application servers that are required to support a given user base can be substantially reduced because a 64-bit environment does not require worker processes to cycle as often. This reduced cycling results in fewer lost connections, improved I/O handling, and a better user experience.
Lower total cost of ownership
All the benefits of 64-bit operation that are listed in the previous sections enable you to do more with less. A 64-bit environment allows you to manage more data, serve more users, and run more applications while using less hardware. By reducing hardware, you are also able to reduce license, operations, and infrastructure costs. It takes up less floor space in your data center and costs less to maintain. Finally, because a Windows SharePoint Services 3.0 farm that uses 64-bit hardware and software provides more room for growth, you can spend less over time on equipment because the life cycle of your equipment is likely to be longer.
4. Explain the new features of windows Server 2008, such as Server core, Virtualization, and PowerShell. What is the role of these features and how will they improve efficiency in administering Windows?
Windows Server 2008 Hyper-V is a new role in Windows 2008 that allows you to create and manage a virtualized server environment. You can run multiple servers inside of one server. This feature will allow you to consolidate many servers onto fewer servers. Like other virtualization products, Hyper-V can provide more efficient use of hardware and administrative resources.
1. Support for Virtual LANs.
2. Large amount of memory for the virtual machines,
3. Ability to run 32bit and 64bit machines at the same time,
4. Up to 32GB of RAM and 4 CPUs in each guest OS,
5. Support for either one processor or multiple processor support for the virtual machines,
6. Support for Snapshots, used to capture the state of a virtual machine at a certain times. You can revert back to that snapshot at any time.
7. Support for quick migration - allowing you move a virtual machine from one server to another without having shut down that virtual machine (not to be confused with live migration where there is no host downtime, comparable to VMware’s VMotion),
8. Support for network load balancing between the virtual machines,
9. Future integration with Microsoft Virtual Machine Manager (VMM) as its centralized management platform.
A Server Core installation provides a minimal environment for running specific server roles, which reduces the maintenance and management requirements and the attack surface for those server roles. A server running a Server Core installation supports the following server roles:
• Active Directory Domain Services (AD DS)
• Active Directory Certificate Services (AD CS)
• Active Directory Lightweight Directory Services (AD LDS)
• DHCP Server
• DNS Server
• File Services
• Print Services
• Streaming Media Services
• Internet Information Services (IIS)
• Hyper-V
The Server Core installation option of Windows Server 2008 and R2 provides the following benefits:
• Reduced maintenance - Because the Server Core installation option installs only what is required to have a manageable server for the AD DS, AD LDS, AD CS, DHCP Server, DNS Server, File Services, Print Services, Web Server and Hyper-V server roles, less maintenance is required than on a full installation of Windows Server 2008.
• Reduced attack surface - Because Server Core installations are minimal, there are fewer applications running on the server, which decreases the attack surface.
• Reduced management - Because fewer applications and services are installed on a server running the Server Core installation, there is less to manage.
• Less disk space required - A Server Core installation requires only about 1.5 gigabyte (GB) of disk space to install and approximately 2 GB for operations after the installation.
• Lower risk of bugs - Reducing the amount of code can help reduce the amount of bugs
The following changes are available in Windows PowerShell in Windows Server 2008 R2:
• New cmdlets. Windows PowerShell includes more than 100 new cmdlets, including Get-Hotfix, Send-MailMessage, Get-ComputerRestorePoint, New-WebServiceProxy, Debug-Process, Add-Computer, Rename-Computer, and Reset-ComputerMachinePassword.
• Remote management. You can run commands on one computer or on hundreds of computers by using a single command. You can establish an interactive session with a single computer, or you can establish a session that can receive remote commands from multiple computers.
• Windows PowerShell Integrated Scripting Environment (ISE). Windows PowerShell ISE is a graphical user interface for Windows PowerShell that lets you run commands and write, edit, run, test, and debug scripts in the same window. It offers up to eight independent execution environments and includes a built-in debugger, multiline editing, selective execution, syntax colors, line and column numbers, and context-sensitive Help. Windows PowerShell ISE is an optional feature of Windows Server 2008 R2. To install it, use the Add Features Wizard.
• Background jobs. With Windows PowerShell background jobs, you can run commands asynchronously and "in the background" so you can continue to work in your session. You can run background jobs on a local or remote computer, and you can store the results locally or remotely.
• Debugger. The Windows PowerShell debugger can help you debug functions and scripts. You can set and remove breakpoints, step through code, check the values of variables, and display a call-stack trace.
• Modules. Windows PowerShell modules let you organize your Windows PowerShell scripts and functions into independent, self-contained units. You can package your cmdlets, providers, scripts, functions, and other files into modules that you can distribute to other users. Modules are easier for users to install and use than Windows PowerShell snap-ins. Modules can include any type of file, including audio files, images, Help files, and icons. Modules run in a separate session to avoid name conflicts.
• Transactions. Windows PowerShell now supports transactions, which let you manage a set of commands as a logical unit. A transaction can be committed, or it can be completely undone so that the affected data is not changed by the transaction.
• Events. Windows PowerShell includes a new event infrastructure that lets you create events, subscribe to system and application events, and then listen, forward, and act on the events synchronously and asynchronously.
• Advanced functions. Advanced functions behave just like cmdlets, but are written in the Windows PowerShell scripting language instead of in C#.
• Script internationalization. Scripts and functions can display messages and Help text to users in multiple languages.
• Online Help. In addition to Help at the command line, the Get-Help cmdlet has a new online parameter that opens a complete and updated version of each Help topic on Microsoft TechNet.
5. What is a Read only Domain Controller (RODC) and what are its advantages? What are the security and administrative issues addressed by a RODC?
Read-only domain controllers (RODCs) are a new feature of Active Directory Domain Services (AD DS) in Windows Server 2008. RODCs are additional domain controllers for a domain that host complete, read-only copies of the partitions of the Active Directory database and a read-only copy of the SYSVOL folder contents. By selectively caching credentials, RODCs address some of the challenges that enterprises can encounter in branch offices and perimeter networks (also known as DMZs) that may lack the physical security that is commonly found in datacenters and hub sites. RODCs also offer a number of manageability improvements that are described in this guide. This section describes how RODCs work with the rest of the Active Directory environment, the main differences between RODCs and writable domain controllers, and the RODC features that can help resolve a number of security or manageability issues.
Advantages That an RODC Can Provide to an Existing Deployment
Security
The following new features that are associated with RODCs can provide security benefits for your deployment:
• Unidirectional replication. Unidirectional replication refers to how RODCs can replicate changes inbound but outbound replication does not occur. No other domain controllers replicate changes from an RODC. Unidirectional replication helps to improve security by restricting potentially malicious updates that can originate in a branch office. Because no changes can replicate from an RODC, only the RODC in the branch office can be compromised.
• Special krbtgt account. Each RODC has a special krbtgt account that also helps to restrict malicious updates from affecting the rest of the forest. The RODC can issue a ticket-granting ticket (TGT) based on its krbtgt account to security principals whose passwords can be cached locally. If a TGT that an RODC issues is used to request a service ticket from a writable domain controller, the authorization data in the TGT is discarded and recalculated before it is added to the TGT.
This means that the krbtgt account for an RODC is useful only in the local branch where the RODC is deployed. Even if an RODC is compromised, a user cannot use a ticket that has been maliciously created by a compromised RODC to access resources in a different site.
For example, suppose that a user in branch A tries to access a resource in branch B. If the password for the resource is cached on the RODC in branch A and connectivity is available, the Privileged Authentication Certificate (PAC) that the RODC in branch A creates can be used to access the resource. However, if the password for the resource cannot be cached on the RODC in branch A, the RODC in branch A will forward the request to a hub site domain controller.
The hub site domain controller discards the PAC from the TGT, recalculates the PAC, and then makes the connection. This way, a branch-signed krbtgt can be used at any writable Windows Server 2008 domain controller in the forest for service tickets for any resource in the forest, but an attacker cannot modify a PAC on an RODC and use that PAC to access resources that cannot be cached by that RODC.
• Password Replication Policy (PRP). Each RODC has a PRP that, by default, does not allow any passwords to be cached on the RODC. This helps ensure that you can deploy RODCs more securely, because, if the default configuration is unchanged, no account passwords can be obtained from a compromised RODC.
• RODC filtered attribute set (FAS). You can also restrict which application data can replicate to RODCs in your forest by adding attributes to the RODC FAS and marking them as confidential. When the attributes are prevented from replicating to RODCs and marked as confidential, that data cannot be exposed on an RODC that is stolen or compromised.
Manageability
The following new features that are associated with RODCs can provide manageability benefits for your deployment:
Branch office server administration. RODCs provide Administrator Role Separation (ARS), which you can use to delegate administration of an RODC to a non-administrative user or group. This means that it is not necessary for a highly privileged administrator to log on to the domain controller in the branch office to perform routine server maintenance.
Domain administrators, on the other hand, can continue to remotely manage directory service issues on the RODC as necessary. However, you should not use a domain administrator account to log on to an RODC or to log on to a workstation that is serviced by an RODC.
Branch office application administration. You might also deploy an RODC for special requirements related to administering applications in a branch office. For example, it might be necessary to run a line-of-business (LOB) application on a domain controller in the branch office. To administer the application, the LOB application owner must log on to the domain controller interactively or by using Terminal Services.
In this case, an RODC can provide a secure mechanism for granting non administrative domain users the right to log on to the domain controller without jeopardizing the security of Active Directory Domain Services (AD DS). Furthermore, any Active Directory data that is tampered with locally cannot replicate from the RODC to other domain controllers.
Scalability
The following new features that are associated with RODCs can provide scalability benefits for your deployment:
Unidirectional replication. Writable domain controllers that are replication partners do not have to pull changes from an RODC. This applies to both AD DS and Distributed File System (DFS) Replication of SYSVOL. In larger branch office environments, inbound replication typically puts a significant load on bridgehead servers in a hub site because it is serialized, which means that the bridgehead server cannot process changes from all of its replication partners simultaneously. RODCs that are deployed in the spoke sites can relieve the inbound replication load on bridgehead servers in the hub site because they never replicate any changes.
This can help to reduce the number of domain controllers that you need to deploy in the hub site. The total number of connection objects that have to be created is also reduced by about half, because inbound connection objects do not have to be created on the hub domain controllers for each branch domain controller. Consequently, you do not have to plan for as much configuration of hub site Windows Server 2008 domain controllers as compared with Windows Server 2003 domain controllers.
This can also help to reduce the end-to-end synchronization time for an enterprise. Writable domain controllers in the hub can be configured to replicate updates to a higher number of RODCs concurrently. This can help to implement security changes, such as updates for fine-grained password policies or updates to the RODC FAS, more rapidly.
DFS Replication versus FRS for SYSVOL replication. Windows Server 2008 contains both the File Replication Service (FRS) and Distributed File System (DFS) Replication for replicating SYSVOL. FRS enables interoperability with domain controllers that run Windows 2000 Server or Windows Server 2003. DFS Replication is used to replicate SYSVOL if the domain functional level is Windows Server 2008.
Due to some limitations with how SYSVOL can be restored when it is replicated by FRS in a large-scale environment, the Windows Server 2003 Branch Office Guide recommended that you not exceed 1,200 domain controllers in a domain. Existing branch office deployments might include multiple domains because of this limitation. For example, if you had more than 1,200 branch offices and you wanted to place a domain controller in each branch, you may have created multiple domains.
DFS Replication is a new state-based, multimaster replication engine that supports scheduling and bandwidth throttling. It uses a new compression algorithm to replicate only the changes—not the entire files—when files are updated. This helps DFS Replication to scale up to include a larger number of domain controllers in a domain than can be used with FRS. However, if you want to use DFS Replication, the domain functional level must be Windows Server 2008. You have to continue using FRS to replicate SYSVOL until all domain controllers in the domain are running Windows Server 2008. Plan for migrating from FRS to DFS Replication, and then perform the migration. For more information about planning for the migration,
DC Locator improvements. Domain controller Locator (DC Locator) is a mechanism that clients use to discover the closest domain controller. Windows Server 2008 includes a new Registry or Group Policy setting that enables Windows Vista and Windows Server 2008 client computers to attempt to locate the next closest domain controller if the closest domain controller is not available. The Try Next Closest Site setting improves the performance of DC Locator by helping to streamline network traffic, especially in large enterprises that have many branch offices and sites. By default, DC Locator does not consider a site that has an RODC when it determines which site is the next closest site. If necessary, you can modify the default behavior of the clients (by modifying the NextClosestSiteFilter value on the Windows Server 2008 or Windows Server 2008 R2 domain controllers that respond to client DC Locator requests) so that clients do consider a site that has an RODC when they determine which site is the next closest site.
Known Issues for Deploying RODCs
Issue Affects Impact Workaround
Group Policy fails to access Windows Management Instrumentation (WMI) filters on an RODC. Client computers in the RODC site If an RODC is available but a writable domain controller is not available, Group Policy fails to access any WMI filters and does not apply any Group Policy object (GPO) to which the WMI filters are linked. Failure to access WMI filters may prevent affected clients from applying intended Group Policy or cause those clients to improperly apply Group Policy that an administrator might have intended the WMI filter to exclude. There is no workaround for this issue.
Internet Protocol security (IPsec) policies fail to apply from an RODC. Client computers in the RODC site (branch office scenario) Attempts by Windows Server 2003 and Windows XP member computers to apply IPsec policies from RODCs fail with Win32 error 8219 (ERROR_POLICY_OBJECT_NOT_FOUND). The same member computers can successfully apply policy from writable domain controllers. You may encounter this scenario when network connectivity for IPsec clients has been limited to Active Directory sites that contain RODCs but no writable domain controllers. There is no workaround for this issue.
The Windows Time service (W32time) in Windows XP and Windows Server 2003 does not recognize an RODC. Client computers in the RODC site (branch office and perimeter network (also known as DMZ) scenarios) the affected client computers will not synchronize time with the RODC during authentication. When the time service gets out of sync, users can receive errors when they attempt to access resources on the network. You can configure the client computers to synchronize time from another domain controller on the network if one is available.
Unsecure domain join fails Client computers in the RODC site (perimeter network scenario) in a perimeter network scenario where an RODC is available but a writable domain controller is not available, unsecure domain joins will fail. Unsecure domain joins are performed by Active Directory Migration Tool (ADMT) and Windows Deployments Service (WDS). There is no workaround for this issue
Domain join using RODC in the perimeter network fails. Client computers in the RODC site (perimeter network scenario) in a perimeter network scenario where an RODC is available but a writable domain controller is not available, domain joins will fail even if the computer account and password are prepopulated on the RODC. You can create firewall rules to allow a writable domain controller to be contacted for the domain join operation, or you can bridge the perimeter and intranet networks. However, most firewall administrators do not allow these options. In that case, you must apply the hotfix or determine a more suitable workaround for your network.
Password changes fail in the perimeter network when only an RODC is available. Client computers in the RODC site (perimeter network scenario) In a perimeter network scenario in which an RODC is available but a writable domain controller is not available, password changes that are initiated from a computer that runs Windows XP, Windows Server 2003, or Windows 2000 will fail. This is true if the user initiates the password change by pressing Ctrl+Alt+Del or if an administrator selects the option that the user must change the password during the next logon, for example, when the administrator creates a new user account. You can create firewall rules that allow a writable domain controller to be contacted for the password change request, you can change the password from within the intranet, or you can perform the password change from a client computer that runs Windows Vista or Windows Server 2008.
The RODC fails to retrieve or create a public key certificate. Client computers in the RODC site (branch office and perimeter network scenarios) The Data Protection Application Programming Interface (DPAPI) on client computers that only have access to an RODC cannot decrypt master keys unless they have previously contacted a writable domain controller and retrieved a public key certificate. Clients that only have access to an RODC cannot decrypt master keys.
Without this fix, even if a writable controller is available, DPAPI on clients may fail to decrypt master keys if the closest domain controller is an RODC. When DPAPI attempts to decrypt master keys, ensure that the client has access only to a writable domain controller. DPAPI attempts to decrypt master keys during password changes.
Spooler does not reflect the correct printer publish state. Client computers in the RODC site (branch office scenario) if an RODC services a client request to publish a printer; it forwards the request to a writable domain controller. The spooler attempts to read from the RODC immediately after the write. The information has not yet been replicated to the RODC, and spooler fails the publish operation. All spooler internal structures are updated, and the printer is marked as unpublished. There is no workaround for this issue.
The Find Printer user interface (UI) hangs when a computer that runs Windows XP or Windows Server 2003 can contact an RODC but not a writable domain controller. Client computers in the RODC site (branch office scenario) Users will not be able to find printers that are published in AD DS. There is no workaround for this issue.
Active Directory Service Interfaces (ADSI) in Windows XP and Windows Server 2003 requests a remote writable domain controller instead of a local RODC. Client computers in the RODC site (branch office scenario) ADSI calls from Windows XP and Windows Server 2003 client computers are directed to a writable domain controller even if an RODC is in the same site as the client. This can cause unnecessary wide area network (WAN) traffic to a writable domain controller in a remote site. Ensure that these client computers have connectivity to a writable domain controller when they make ADSI calls, even for read-only operations. ADSI calls to the writable domain controller will create additional WAN traffic.
Domain controllers running Windows Server 2003 perform automatic site coverage for sites with RODCs. Windows Server 2003 domain controllers that provide automatic site coverage for other branch office sites (branch office scenario) a domain controller running Windows Server 2003 may register its Domain Name System (DNS) service (SRV) resource records for a site that contains an RODC. Consequently, client computers that attempt to discover a domain controller in the RODC site can also find the domain controller that is running Windows Server 2003. As a result, they might not authenticate with the RODC as desired.
You can implement these workarounds if you do not want to apply the hotfix:
• Ensure that only domain controllers running Windows Server 2008 are present in the site that is closest to the RODC site.
• Disable automatic site coverage on domain controllers running Windows Server 2003. For more information about how to disable automatic site coverage