Eddie's Blog

Exchange Server Licensing

One Exchange server license per Exchange server
Exchange Standard v.s Enterprise edition:

5 databases per Standard edition
100 databases per Enterprise edition
For database availability group (DAG), do not need Exchange Enterprise edition; however, must have Windows Server 2008 or Windows Server 2008 R2 Enterprise edition.

One client access license (CAL) per user
Standard v.s. Enterprise CAL:

Enterprise CALs are add-ons to Standard CALs. To buy Enterprise CALs must buy the amount of Standard CALs.
Enterprise CAL features:

Unified messaging
Custom retention policies
Advanced Exchange ActiveSync policies
Per-user or per-distribution-list journaling
Personal Archive feature
Multi-mailbox search
Information protection and control feature set

Comparison of Exchange ActiveSync Clients

http://en.wikipedia.org/wiki/Comparison_of_Exchange_ActiveSync_Clients

Windows 7 or Windows Vista Wake Timer

Windows Vista and later support wake timers that scheduled tasks can use, allowing a system to automatically wake from sleep or hibernate at a certain time.

Schedule a task:

Launch Task Scheduler, Conditions tab, select Wake the computer to run this task.

List all active wake timers

Cmd, powercfg –waketimers

List all devices that are capable of waking a machine from sleep

Cmd, powercfg –devicequery wake_armed

Setup Windows Server 2008 and R2 DHCP Scope

Q. How do I create a DHCP scope in Windows Server 2008 and Server 2008 R2?

A. DHCP is a key service to enable the dynamic allocation of IP addresses to your network. Without DHCP, each machine has to be manually configured with an IP address, gateway, and DNS information. This might work for a small number of servers, but in any sizable environment, the ability for clients to dynamically get IP addresses is vital.

Windows has long had a DHCP service, and it has improved with each new version. In Server 2008 and later, DHCP is a server role that's added through Server Manager. Once you've added the DHCP Server role, you need to configure a scope—a set of IP addresses the DHCP service can allocate from to give to requesting clients. It's important that the DHCP scope you define consists of IP addresses that aren't used on any machine in the network (such as statically defined on a server) nor part of a scope on another DHCP server. Duplicate IP addresses in an environment will cause major problems, and it's always good practice to have an IP allocation scheme and tracking. Some organizations use IP addresses 10-50 of each subnet for servers and printers, 60-240 for DHCP clients, and so on.

Once the DHCP Server role is installed, you need to authorize the DHCP server by navigating to the DHCP Server role in server manager, selecting the server, and selecting Authorize. You can now create a scope.

Navigate to DHCP Server, the server's name, IPv4.
Select New Scope from the actions.
Click Next to the introduction wizard screen.
You'll be prompted for a name for the scope and a description. Make it meaningful, such as the IP addresses in the scope, and click Next.
Enter the starting IP address, the ending IP address, and the subnet mask detail and click Next.
You can now add specific IP address ranges that should be excluded from the scope. Maybe you have some servers that have IP addresses within the range you're allocating to DHCP, which therefore shouldn't be given to clients. You can also set a delay time, which is the amount of time the DHCP server will wait before responding to DHCP requests. Click Next.
Set the length of time for the IP address lease. The longer the lease time, the less frequent machines have to renew the address—but that means clients keep the address longer. If you have a lot of through traffic of machines on the network, you don't want those machines keeping the lease for long, because your scope will run out of addresses. Set a small lease, maybe a day. Click Next.
You can configure DHCP options, such as default gateway, DNS servers, WINS servers, etc. Or select No and set them later, or at a server level (for things like DNS server etc). Default gateway will likely be different for each scope. Click Next.
Click to activate the scope, and you're done.
If you wanted to select items like DNS and WINS at the server level, the settings apply to all scopes on the server. Select Server Options and you can set global options, as shown here.

Once you have DHCP configured, you can run

ipconfig /renew

on your clients and they should get an IP address from your DHCP server. You can see the address with the command ipconfig.

Configure USB Devices in Windows Virtual PC

Windows Virtual PC has integration features that allow certain types of devices to be shared between the host computer and the virtual machine (VM), including audio devices, clipboard, printers, drivers, and smart cards.

However, the VM may use the generic driver for the USB device, and the device may not work correctly. To install the driver for the USB device,

Disable Integration Features.
Log on again. Under the USB menu, attach the USB device and click Continue to remove the device from the host computer.
Install the USB driver, and test it.
Release the USB device from the VM using the USB menu.
Enable the integration features again, and the USB device should work because the right driver is loaded in the VM.

Install Active Directory Module for Windows PowerShell

See Mike Pferiffer’s Blog below. Notes Active Directory Web Services (ADWS) or Active Directory Management Gateway Service is required to use Active Directory Module. Quest Software ActiveRoles Management Shell for Active Directory’s Get-QADUser without this requirement.

With the release of PowerShell 2.0, we now have a PowerShell module that we can use to administer Active Directory. The Active Directory Module for Windows PowerShell runs on Windows Server 2008 R2 and on Windows 7 and relies on a web service that is hosted on one or more domain controllers in your environment. In this post I'll go over what you need in order to install and use the Active Directory Module for PowerShell, also known as AD PowerShell.

Setting up your Domain Controllers

In order to use the Active Directory Module for Windows PowerShell on 2008 R2 and Windows 7, you first need to be running Active Directory Web Services (ADWS) on at least one Domain Controller. To install Active Directory Web Services (ADWS) you'll need one of the following:

1. Windows Server 2008 R2 AD DS

You can load Active Directory Web Services (ADWS) on a Windows Server 2008 R2 Domain Controller when you install the AD DS role. The AD PowerShell module will also be installed during this process. Active Directory Web Services (ADWS) will be enabled when you promote the server to a DC using DCPromo.

2. Active Directory Management Gateway Service

If you cannot run Windows Server 2008 R2 Domain Controllers, you can install the Active Directory Management Gateway Service. Installing this will allow you to run the same Active Directory web service that runs on Windows Server 2008 R2 DC's. You can download the Active Directory Management Gateway Service here. Make sure you read the instructions carefully, there are several hotfixes that need to be applied depending on the version of Windows you are running. You can install the Active Directory Management Gateway Service on DC's running the following operating systems:

Windows Server 2003 R2 with Service Pack 2
Windows Server 2003 SP2
Windows Server 2008
Windows Server 2008 SP2

Note: You can also use AD PowerShell to manage AD LDS instances on Windows Server 2008 R2. If you plan on using AD LDS, Active Directory web services will be installed with the AD LDS role, the AD PowerShell module will also be installed during this process. The ADWS service will be enabled when your LDS instance is created.

Once you've got Active Directory web services up and running on your Domain Controller(s), you'll notice you now have an ADWS service as shown here:

At this point, you should be ready to install the AD PowerShell module. You can run AD PowerShell on all versions of Windows Server 2008 R2 (except the Web Edition) and on Windows 7.

Installing the Active Directory Module for Windows PowerShell on 2008 R2 member servers

You can install the Active Directory Module on Windows 2008 R2 member servers by adding the RSAT-AD-PowerShell feature using the Server Manager. I usually use the ServerManager module to do this because it is quick and easy. To install the feature using the ServerManager module, launch PowerShell and run the following commands:

Import-Module ServerManager
Add-WindowsFeature RSAT-AD-PowerShell

Remember, this only needs to be done on Windows Server 2008 R2 member servers. The RSAT-AD-PowerShell feature will be added to 2008 R2 DC's during the DCPromo process.

Installing the Remote Server Administration Tools (RSAT) feature on Windows 7

In order to install the Active Directory Module for Windows PowerShell you need to download the RSAT tools for Windows 7here. Once this is installed you are still not finished, you need to enable the Active Directory module. Navigate to Control Panel > Programs and Features > Turn Windows Features On or Off and select Active Directory Module for Windows PowerShell as show here:

Once you have Active Directory web services running on at least one domain controller and the AD PowerShell module is installed, you are ready to run the AD PowerShell module. You can do this in one of two ways. First, you can access the "Active Directory Module for Windows PowerShell" shortcut in Administrative Tools as shown here:

Right click the shortcut and select "Run as administrator" in order to start PowerShell with elevated permissions.

You can also simply import the AD PowerShell module in your existing PowerShell session. Just use the Import-Module ActiveDirectory command:

Import-Module ActiveDirectory

That's all that needs to be done to get up and running...I will get into using the AD PowerShell cmldets in future posts so keep an eye out for that.

Upgrade vSphere Virtual Machine

Recap vSphere upgrade process:

Upgrade vCenter Server
Upgrade ESXi Hosts (3.5 to 4.1, 4.0 to 4.1)
Upgrade Virtual Machine Clients (optional. But it’s required if you want to take advantage of the new drivers and features)

The following article is from Scott Lowe with some of my update.

Upgrading a VMware Infrastructure 3.x environment to VMware vSphere 4 involves more than just upgrading vCenter Server and upgrading your ESX/ESXi hosts (as if that wasn’t enough). You should also plan on upgrading your virtual machines. VMware vSphere introduces a new hardware version (version 7), and vSphere also introduces a new paravirtualized network driver (VMXNET3) as well as a new paravirtualized SCSI driver (PVSCSI). To take advantage of these new drivers as well as other new features, you’ll need to upgrade your virtual machines. This process I describe below works really well.

Please note that this process will require some downtime. I personally tested this process with both Windows Server 2003 R2 as well as Windows Server 2008; it worked flawlessly with both versions of Windows.

1. Record the current IP configuration of the guest operating system. You’ll end up needing to recreate it.

2. Upgrade VMware Tools in the guest operating system. You can do this by right-clicking on the virtual machine and selecting Guest > Install/Upgrade VMware Tools. When prompted, choose to perform an automatic tools upgrade. When the VMware Tools upgrade is complete, the virtual machine will reboot.

3. After the guest operating system reboots and is back up again, shutdown the guest operating system. You can do this by right-clicking on the virtual machine and selecting Power > Shutdown Guest.

4. Upgrade the virtual machine hardware by right-clicking the virtual machine and selecting Upgrade Virtual Hardware.

5. In the virtual machine properties, add a new network adapter of the type VMXNET3 and attach it to the same port group/dvPort group as the first network adapter.

6. Remove the first/original network adapter.

7. Add a new virtual hard disk to the virtual machine. Be sure to attach it to SCSI node 1:x; this will add a second SCSI adapter to the virtual machine. The size of the virtual hard disk is irrelevant.

8. Change the type of the newly-added second SCSI adapter to VMware Paravirtual.

9. Click OK to commit the changes you’ve made to the virtual machine.

10. Power on the virtual machine. When the guest operating system is fully booted, log in and recreate the network configuration you recorded for the guest back in step 1. Windows may report an error that the network configuration is already used by a different adapter, but proceed anyway. Once you’ve finished, shut down the guest operating system again.

11. Edit the virtual machine to remove the second hard disk you just added.

12. While still in the virtual machine properties, change the type of the original SCSI controller to VMware Paravirtual (NOTE: See update below.)

13. Power on the virtual machine. When the guest operating system is fully booted up, log in.

14. Create a new system environment variable named DEVMGR_SHOW_NONPRESENT_DEVICES and set the value to 1.

15. Launch Device Manager and from the View menu select Show Hidden Devices.

16. Remove the drivers for the old network adapter and old SCSI adapter. Close Device Manager and you’re done!

If you perform these steps on a template, then you can be assured that all future virtual machines cloned from this template also have the latest paravirtualized drivers installed for maximum performance.

UPDATE: ~~Per~~ ~~this VMware KB article~~, VMware doesn’t support using the PVSCSI adapter for boot devices. That is not to say that it doesn’t work (it does work), but that it is not supported. Thanks to Eddy for pointing that out in the comments! The VMware KB article has been updated, VMware support using the PVSCSI adapter for boot devices on Windows Server 2008 and Server 2003.

Reference: Scott Lowe – vSphere Virtual Machine Upgrade Process