Windows Server 2008 Edition Comparison (Chart)

Windows Server 2008 comes in several major editions derived from the same code base. The most important differences among editions are in the number of processors, amount of physical memory, and high-availability features supported.

The edition specifically targeted at servers with Itanium CPUs, Windows Server 2008 for Itanium-Based Systems (IA64), is not listed in the chart, but its features and price are almost identical to the Datacenter Edition listed in the rightmost column.

	Windows Server 2008 Web Edition	Windows Server 2008 Standard Edition	Windows Server 2008 Enterprise Edition	Windows Server 2008 Datacenter Edition
Supersedes	Windows Server 2003 Web Edition	Windows Server 2003 R2 Standard Edition Windows Server 2003 R2 Standard x64 Edition	Windows Server 2003 R2 Enterprise Edition Windows Server 2003 R2 Enterprise x64 Edition	Windows Server 2003 R2 Datacenter Edition Windows Server 2003 R2 Datacenter x64 Edition
Hyper-V virtualization technology	Not included	Included1	Included1	Included1
OS instances permitted per server license	One instance (physical or virtual)	One physical instance plus one virtual instance2	One physical instance and up to 4 virtual instances2	Unlimited number of OS instances
Maximum server RAM supported3	32-bit: 4GB 64-bit: 32GB	32-bit: 4GB 64-bit: 32GB	32-bit: 64GB 64-bit: 2TB	32-bit: 64GB 64-bit: 2TB
Maximum number of CPUs	4	4	8	64
Hot swap RAM and CPUs	No	No	No4	Yes
Cluster Service (failover)	No	No	Yes, up to 16 nodes per cluster	Yes, up to 16 nodes per cluster
Terminal Server	No	Yes5	Yes	Yes
Network Access Protection	No	Yes6	Yes	Yes
U.S. estimated retail price7	US$470 per server ( available only without Hyper-V)	US$800 per server (US$772 without Hyper-V)	US$3,000 per server (US$2,972 without Hyper-V)	US$3,000 per processor (US$2,972 per processor without Hyper-V)
CALs or External Connector required8	No	Yes	Yes	Yes

¹ Windows Server 2008 Standard, Enterprise, and Datacenter are also offered in "without Hyper-V" editions that do not include the hypervisor technology.

² When customers exercise the maximum number of OS instances permitted by the server license, the physical OS instance may not be used to run any workload beyond hosting the virtual machines.

³ A single package contains both 32-bit and 64-bit versions. The server license grants the customer the option to use either the 32-bit version or the 64-bit version of the software.

⁴ Supports hot addition of memory, but not hot replacement of memory, nor hot add or replacement of processors.

⁵ Use of Windows Server 2008's new Terminal Services Gateway capability is limited to 250 connections.

⁶ Includes restrictions limiting scalability.

⁷ Volume licensing customers typically receive additional discounts of 10% to 30%.

⁸ Client Access Licenses (CALs) retail for US$40 apiece but are offered to volume customers for as much as 50% off. External Connectors are available only via volume licensing programs. Pricing for an External Connector starts at approximately US$1,800 in the least-discounted programs.

How to Run PowerShell Commands on Remote Computers

PowerShell Remoting allows you to run individual PowerShell commands or access full PowerShell sessions on remote Windows systems. It’s similar to SSH for accessing remote terminals on other operating systems.

PowerShell is locked-down by default, so you’ll have to enable PowerShell Remoting before using it. This setup process is a bit more complex if you’re using a workgroup – for example, on a home network — instead of a domain.

Enabling PowerShell Remoting

On the computer you want to access remotely, open a PowerShell window as Administrator – right click the PowerShell shortcut and select Run as Administrator.

To enable PowerShell Remoting, run the following command (known as a cmdlet in PowerShell):

Enable-PSRemoting -Force

This command starts the WinRM service, sets it to start automatically with your system, and creates a firewall rule that allows incoming connections. The -Force part of the command tells PowerShell to perform these actions without prompting you for each step.

Workgroup Setup

If your computers aren’t on a domain – say, if you’re doing this on a home network – you’ll need to perform a few more steps. First, run the Enable-PSRemoting -Forcecommand on the computer you want to connect from, as well. (Remember to launch PowerShell as Administrator before running this command.)

On both computers, configure the TrustedHosts setting so the computers will trust each other. For example, if you’re doing this on a trusted home network, you can use this command to allow any computer to connect:

Set-Item wsman:\localhost\client\trustedhosts *

To restrict computers that can connect, you could also replace the * with a comma-separated list of IP addresses or computer names.

On both computers, restart the WinRM service so your new settings will take effect:

Restart-Service WinRM

Testing the Connection

On the computer you want to access the remote system from, use the Test-WsMan cmdlet to test your configuration. This command tests whether the WinRM service is running on the remote computer – if it completes successfully, you’ll know that WinRM is enabled and the computers can communicate with each other. Use the following cmdlet, replacing COMPUTER with the name of your remote computer:

Test-WsMan COMPUTER

If the command completes successfully, you’ll see information about the remote computer’s WinRM service in the window. If the command fails, you’ll see an error message instead.

Executing a Remote Command

To run a command on the remote system, use the Invoke-Command cmdlet. The syntax of the command is as follows:

Invoke-Command -ComputerName COMPUTER -ScriptBlock { COMMAND } -credential USERNAME

COMPUTER represents the computer’s name, COMMAND is the command you want to run, and USERNAME is the username you want to run the command as on the remote computer. You’ll be prompted to enter a password for the username.

For example, to view the contents of the C:\ directory on a remote computer named Monolith as the user Chris, we could use the following command:

Invoke-Command -ComputerName Monolith -ScriptBlock { Get-ChildItem C:\ } -credential chris

Starting a Remote Session

Use the Enter-PSSession cmdlet to start a remote PowerShell session, where you can run multiple commands, instead of running a single command:

Enter-PSSession -ComputerName COMPUTER -Credential USER

Windows Vista, Windows 7 startup process

The startup process of Windows Vista, Windows Server 2008, Windows 7 and Windows Server 2008 R2 is different from previous versions of Windows. For Windows Vista, the boot sector loads the Windows Boot Manager (hidden system file BOOTMGR in the C: root directory), which first looks for an active partition, then accesses the Boot Configuration Data store and uses the information to load the operating system.

Boot Configuration Data

Boot Configuration Data (BCD) is a firmware-independent database for boot-time configuration data. It replaces the boot.ini that was used by NTLDR, and is used by Microsoft's new Windows Boot Manager.
Boot Configuration Data are stored in a data file that has the same format as the Windows Registry.^[1] The file is located either on the EFI System Partition (on machines that use Extensible Firmware Interface firmware) or in \Boot\Bcd on the system volume (on machines that use IBM PC compatible firmware).

Boot Configuration Data may be altered using a command-line tool (bcdedit.exe), using Registry Editor (regedit.exe), using Windows Management Instrumentation, or with third party tools like EasyBCD.
Boot Configuration Data contain the menu entries that are presented by the Windows Boot Manager, just as boot.ini contained the menu entries that were presented by NTLDR. These menu entries can include:

• Options to boot Windows Vista by invoking winload.exe.
• Options to resume Windows Vista from hibernation by invoking winresume.exe.
• Options to boot a prior version of the Windows NT family by invoking its NTLDR.
• Options to load and to execute a volume boot record.

Boot Configuration Data allows for third party integration so anyone can implement tools like diagnostics or recovery options.

winload.exe  

The Windows Boot Manager invokes winload.exe—the operating system boot loader—to load the operating system kernel (ntoskrnl.exe) and (boot-class) device drivers. In that respect, winload.exe is functionally equivalent to the operating system loader function of NTLDR in prior versions of Windows NT.

 

Uninstall the KMS host

Uninstall the KMS host key first by running the following command:

slmgr -upk

2. Then,
install the default kms key by running the following command:

slmgr
/ipk [KMS Client Setup Key]

The default KMS client setup keys can be found here:

http://technet.microsoft.com/en-us/library/cc303280.aspx

3. Delete the record from the DNS:
Open DNS console:

Expand _tcp node under the domain.com. There will
be a record _VLMCS. Delete this record.

4. The KMS server is uninstalled.

Running Slmgr.vbs Remotely

slmgr.vbs TargetComputerName [username] [password] /parameter [options]

Table 3. Slmgr.vbs Parameters

Parameter	Description
/sprt PortNumber	Sets the TCP communications port on a KMS host. Replace PortNumber with the TCP port number to use. The default setting is 1688.
/cdns	Disables automatic DNS publishing by a KMS host.
/sdns	Enables automatic DNS publishing by the KMS host.
/cpri	Lowers the priority of KMS host processes.
/spri	Sets the priority of KMS host processes to Normal.
/sai ActivationInterval	Changes how often a KMS client attempts to activate itself when it cannot find a KMS host. Replace ActivationInterval with a number of minutes. The default setting is 120.
/sri RenewalInterval	Changes how often a KMS client attempts to renew its activation by contacting a KMS host. Replace RenewalInterval with a number of minutes. The default setting is 10080 (7 days). This setting overrides the local KMS client settings.
/dli	Retrieves the current KMS activation count from the KMS host.

HRESULT: 0x800f0818 Unable to add/modify Roles or Features through Server Manager or Powershell after installing updates

After installing numerous Windows Updates, usually when bringing a newly installed server up to date on patches, you may recieve the following error in server manager:

Error: Unexpected error refreshing Server Manager: Exception from HRESULT:0x800F0818d

This issue occurs when corrupt .mum or .cat files are present after the extraction and installation process of windows updates.

To reolve this we need to complete a few steps

1. Download and run the Microsoft Update Readiness Tool from http://support.microsoft.com/kb/947821 once it has run check the log in C:\Windows\Servicing\Packages\CheckSUR.log or %SYSTEMROOT%\Logs\CBS\CheckSUR.log

2. You should see errors resembling:
CBS MUM Corrupt 0×00000000 servicing\Packages\Package_for_KB978601~31bf3856ad364e35~amd64~~6.0.1.0.mum Expected file name Package_for_KB978601_server~31bf3856ad364e35~amd64~~6.0.1.0.mum does not match the actual file name

and further down

Unavailable repair files:
servicing\packages\Package_for_KB978601~31bf3856ad364e35~amd64~~6.0.1.0.mum

3. There may be more than one problematic update so make a note of all of them, you will then need to download these KB’s and unpack them using the following commands:

Expand -F:* UpdateKB978601.msu C:\Directory

This then shows a cat file which also needs to be unpacked:

Expand -F:* UpdateKB978601.CAB C:\Directory\CAB

 you can use any software to extract CAB files like Izarc.

4. You will need to grab the two files, one extension .mum and one extension .cat, then rename them making sure they are exactly as was displayed in the CheckSUR.log file. You will then need to copy them into the C:\Windows\Servicing\Packages directory overwriting the existing ones.

These steps should resolve the issues and you should be able to add/remove Roles and Features again