Step-by-Step: Publishing a Single Exchange 2003 OWA with ISA 2004 Firewall Forms Based Authentication

I decided to take the DIY approach for setting ISA firewall to securely publish Exchange 2003 Outlook Web Access using forms-based authentication and SSL bridging to provide a higher level of security in web mail access. I believe this step-by-step article will take out some of the guess work that I went through when checking the configuration.

Step-by-Step:
Publishing a Single Exchange 2003 OWA with
ISA 2004 Firewall Forms Based Authentication by Liran Zamir
By Liran Zamir

Got questions? Discuss this article over at
http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000106
I decided to take the DIY approach for setting ISA firewall to securely publish Exchange 2003 Outlook Web Access using forms-based authentication and SSL bridging to provide a higher level of security in web mail access. I believe this step-by-step article will take out some of the guess work that I went through when checking the configuration.

The procedures in this article will not work for multiple Exchange server environments as the publishing rule can only redirect request to a single server. If implemented in a multiple server environment, users will only be able to access OWA mailboxes located on the published server. I presume that in a multiple server environment the procedure could be configured only when the actual published server is an Exchange front-end server.
The advantage of publishing Exchange Outlook Web Access (OWA) using the ISA firewall's Forms-Based authentication is the ability to off load the authentication of web clients from the Exchange server to the ISA firewall, and to prevent unauthenticated communication from reaching the Exchange server. The ISA firewall's Forms-Based authentication works with Exchange 5.5, 2000 and 2003.
This article will focus on Exchange 2003, where a web site certificate is used for two purposes:

1. Provide SSL communication between the remote client and the ISA firewall.
2. Provide SSL communication between the ISA firewall and the Exchange server.

This will create an SSL to SSL bridge where the SSL communication from the remote client is terminated at the ISA firewall, and another SSL session is created between the ISA firewall and the exchange server. The remote client does not actually connect directly to the Exchange server over SSL.
Steps for deployment:
Preparing the Exchange server 2003 and certificates.Decision point – Which certificates to use
Create your own certificates
Generating the web site certificate request
From a request to a certificate
Importing the certificates to the ISA firewall.Checking SSL connectivity between the ISA firewall and the OWA site
Importing the certificates
Checking Browser connectivity from ISA to the OWA site
Configure the ISA Web Listener and Publishing rule.
Verify External connectivity.

Preparing the Exchange server 2003 and certificates.

NOTE! Do not enable forms-based authentication on the Exchange server itself.

The first step to take is to configure your internal Exchange 2003 server to use a web site certificate for client connections. The clients may be internal or external network clients, as far as the Exchange server is concerned. Since in our case remote clients will actually connect to the ISA firewall, the ISA firewall itself will act as a client to the OWA web site. The Exchange server OWA web site can be configured to require SSL communication only, but this article will not cover this issue as it is usually not necessary to encrypt OWA connections within the internal network.

Decision point – Which certificates to use?

The best way to approach the use of certificates for a publicly accessible web site is to acquire a certificate from a known Certificate Authority such as Verisign.
The advantage of such certificate is that the issuer (the company which owns the certificate authority who generated the certificate) is already trusted by Windows based computers. You can use Internet Explorer's Internet Options and Content tab to see the list of trusted certificate authorities. Another option is to open an mmc console and use the Certificates snap-in to view the list of Trusted Root Certificate Authorities.

If you cannot afford the purchase of a publicly signed certificate, you can issue your own certificates using a Windows 2000/2003 server, with the free Certificate Authority services within those network operating systems.

Note!
In some cases, such as when using the Exchange 2003 RPC over HTTP feature, you will be required to manually import the home-brewed CA certificate to the client computers in order for those computers to trust the unfamiliar Certificate Authority.

Create your own certificates

To issue your own certificate from a Windows 2003 server, use the following steps to install the required components.
Open Add/Remove programs, and select Add/Remove Windows components.
To make the process to issuing certificates easier, you should install both
the IIS server and the Certificate Services which include both the Certificate Authority installation and the Certificate Services Web Enrolment support.

During the installation process you will be asked to select which type of Certificate Authority you would like to install. If the sole reason you install the CA is to generate a web site certificate, select a "Stand-Alone root CA". In a larger environment when PKI infrastructure is deployed you should check if an Enterprise root CA is installed - which will be able to issue the certificates.

Continue the installation process; provide a common name for the CA. I suggest you enter the public domain that you are using. In the following case I used my own registered domain name: liran.org

Accept the installation defaults and finish the installation.
When done, you will notice that on the CA server, a CA certificate is placed in the %windir%\system32\certsrv\CertEnroll folder. You will need to import the CA certificate to the trusted root Certificate Authorities store on the ISA firewall later on.

Generating the web site certificate request

Log on to the Exchange 2003 server you intend to publish. Open the Internet Information Services (IIS) Manager tool from the Administrative Tools menu, and expand the web sites tree. Locate and click Properties on the Default Web Site, which holds the OWA virtual directories. Select to the Directory Security tab, and click Server Certificate…. In the Wizard select: Create a new certificate.

Select to Prepare the request now, but send it later, and click Next. Leave the certificate name as Default Web Site, and the Bit Length: 1024 and click Next. Type the name of your organization and an OU, and click Next. In the Common Name window, make sure to enter the exact FQDN that will be used by external users to access the OWA web site. If the following example I used owa.liran.org. You should register this record with your publicly available DNS service provider for your domain. This record should point to the ISA firewall external interface IP address.

Note!
For smaller companies, the external IP address of the ISA firewall may already be configured on your public DNS for your domain as the MX record with a name such as mail.liran.org . When creating the certificate, you may use this record as the certificate common name, and save some time on calling the DNS provider for additional DNS record registration, but I will advise against it as you might want to set up a mail gateway in the future which will use the mail.liran.org as the MX record, but will no longer point to the ISA External interface IP address. The is no problem having more then one DNS record pointing to a single IP address, so just add another host record such as owa.liran.org.

Continue running the certificate wizard, enter additional information in the Geographical Information page. In the Certificate Request File Name page make sure to note the location and file name of the certificate request file. The default location is c:\certreq.txt. Continue the process and click Finish.

Form a request to a certificate

To approve the certificate request, open a web browser on the Exchange server and enter the URL to the CA server. For example: http://CAServer/CertSrv (replace CAServer with the IP address or computer name of your CA server) On the Certificate Services Welcome screen, click Request a certificate. Select advanced certificate request, and click Submit a certificate request by using…. On the Submit a Certificate Request or Renewal Request page focus on the Saved Request window.
Open the request file generated earlier, (c:\certreq.txt), with notepad, and copy the content code between the Begin and End sections, and paste into the Saved Request window.

When done click Submit. Wait for the Certificate Pending, and close the web browser. Log on to the certificate server, open the Certification Authority console from the Administrative tools menu. Expand the CA, and navigate to the Pending Requests tree. On the right pane you will see the certificate request just waiting there to be approved. Right click the certificate and select All Tasks and then Issue. The issued certificate will be moved to the Issued Certificates container.

Go back to the Exchange server, and open the web browser. Again point to http://CAServer/CertSrv , and click View the status of a pending certificate request. Click the saved request certificate link, and select Download certificate using the DER Encoded. Save the file certnew.cer to the Exchange server desktop. Open the IIS console on the Exchange server, and again navigate to the Directory Security tab of the Default Web Site. Click Server Certificate… and use the wizard to process the pending request. Provide with the certnew.cer file, verify port 443 as the SSL port, click Next, Finish, and OK to close the properties page. Restart the Default web site.
At this point, the Default web site is SSL enabled, which means you can access it using either HTTP or HTTPS.
If you try to access the OWA web site using a web browser with https://, you might be prompted with an Alert such as the following one:

Note that the Alert contains three parts as explained:
a. Warning will appear if the CA that generated the certificate is not trusted.In case you generated the certificate yourself from a privately installed CA,
you will need to import the CA certificate to the computer Trusted root
certificate authorities store. This is NOT required process on every client
unless you find this message very annoying.
b. Warning will appear if the certificate dates are invalid. This could happen if the date scope of the certificate does not match
the date settings on the browsing computer, or if the certificate dates
themselves either will start in the future or already ended.
c. Warning will appear if contacting with a URL that is different for the certificate common name.
In the above example I used the server NetBIOS name instead of
https://owa.liran.org/exchange, which caused the alert to appear.
In order for ISA firewall to properly publish the secured web site, you must make sure that SSL connection to the OWA web site will not fail any of the above tests. This will be covered later on.

Importing the certificates to the ISA firewall.

The ISA firewall will require the web site certificate with its private key to make client-to-ISA SSL connections, and ISA-to-OWA SSL connections. You should export a copy of web site certificate for a later use.
To do so, return to the Directory Security tab of the default web site on the Exchange server, and click View Certificate. On the certificate window, select the details tab, and click Copy to file. In the wizard, select Yes, export the private key, select to enable strong protection, set a password, and select to save the certificate to a file named c:\owasitecert.pfx. Copy the file to the ISA firewall hard drive. As I explained at the last section on step 1, the ISA 2004 server must be able to perform SSL client connectivity to the Exchange secured OWA site without any warning messages.

Checking SSL connectivity between ISA 2004 and the OWA site

Make sure SSL connection can be made from the ISA firewall to the Exchange server. Open a CMD console, and enter the following line to test SSL connectivity: telnet ExchangeIP 443. (Replace ExchangeIP with the Exchange server internal network IP address).
If a connection could not be made, create a computer definition for the Exchange server in the ISA console, and then create an access rule to allow HTTPS from LOCALHOST to the Exchange server computer object. Check connectivity again using telnet. When the connection could be made, continue by importing the required certificates to the ISA firewall.

Importing the certificates

On the ISA firewall, click Start -> Run, type mmc and click OK. In the new console either click CRTL+M, or select Add/Remove Snap-in from the file menu. On the Standalone tab, click Add, and select Certificates. Select Computer Account, and click Next. Select Local Computer and click Finish. Click Close and OK.
In the console, expand Certificates (Local computer), and navigate to Trusted root Certificate Authorities -> Certificates. Try to locate the Certificate server certificate. It should be named as your external domain name if you used my suggestion earlier for naming the CA. (This is not required if using 3^rd party certificate) If you cannot find the certificate, you will need to import it. Copy the .crt file from the \system32\certsrv\CertEnroll folder of the Certificate authority server to the ISA firewall.
Back on the ISA firewall, right click the copied certificate, and select Install Certificate. Click Next, and select Place all certificates in the following store. Click Browse, enable Show physical stores, expand the Trusted root certificate authorities, and select Local Computer. Click OK, Next and Finish. You will be prompted with a security warning, click Yes, and OK to confirm the certificate installation.
To confirm the certificate installation, refresh the Trusted root Certificate Authorities certificate list and verify the certificate can be located.

Keep the certificate console open on the ISA firewall.
Next, you will need to import the Web site certificate to the ISA firewall.
Use the certificates console again.
In the Console tree, expand Certificates (Local Computer), and select the Personal container. Right click Personal and select All Tasks -> Import. Use the Browse to locate the owasitecert.pfx file you copied from the Exchange server earlier, provide the password, and place the imported certificate to the personal certificate store. When down, refresh the personal store and locate the imported web site certificate under Personal -> Certificates.
The certificate will be named based on the Common Name you selected for the published web site.

Close the Certificates console. You are not required to save it.

Checking Browser connectivity from ISA to the OWA site

Now we will check if the ISA firewall can connect to the OWA web site. As explained on the first section of the article, a few checks are made when connecting to a site with an SSL certificate.
We already covered the importing of the CA certificate to the ISA firewall, so the CA should already be trusted.
I assume that the web site certificate dates are valid as well as the date/time configuration on the ISA firewall clock, so we are only left with making sure that the URL used to connect to the OWA site is the one specified in the common name. This means that in our lab case, we should be able to resolve the URL owa.liran.org from the ISA firewall to the Exchange server internal IP address.
If the ISA firewall cannot resolve the common name (owa.liran.org) to the Exchange IP address using DNS, (test by performing a ping command), you should edit ISA firewall's hosts file (located in the %systemroot%\SYSTEM32\DRIVERS\etc folder) to include a name to IP translation of the common-name FQDN to the Exchange IP address. After updating the HOSTS file, try to ping the FQDN again, and verify that the ping request indeed tries to ping the Exchange IP address. Note that we are looking for a successful name resolution and not a successful ping as ping traffic might be blocked by the ISA firewall default rule.
Open a web browser on the ISA firewall, and enter the URL for test. The URL should be in the form of: https://common-name/exchange (You should replace the common name with the actual FQDN). If you are getting the Security Alert message, you should resolve the cause of the problem and try again. If you are unable to access the site at all, disable any web proxy settings in the browser LAN Settings and try again. Do NOT delete the added entry to the hosts file!
After resolving any problems you might have, you will be able to connect and logon to a mailbox on the Exchange OWA web site using basic authentication pop-up window. Form based authentication will be performed for remote clients by the ISA firewall.

Configure the ISA 2004 Listener and Publishing rule

In our example, the ISA firewall is configured with two network adapters. The first adapter connects to the LAN and the second adapter to the Internet. To publish the OWA web site, we will open the ISA management console, and navigate to the Firewall Policy on the left pane. On the right pane, expand the Task Pane. Click Publish a mail server on the Tasks tab. The Welcome to the new mail server publishing rule wizard will appear. Select your desired rule name and click Next. Select Web Client Access, and click Next. On the Select Services page, make sure that Outlook Web Access is selected and click Next.

On the Bridging Mode page select Secure Connection to client and mail server.
On the Specify the Web Mail Server page, type the FQDN of the published site (not the IP address, not the NetBIOS name and not the internal domain FQDN unless the full server name of the Exchange server in the internal Active Directory DNS matches the Common name FQDN, which is not likely).

On the Public Name Details page, enter the FQDN again, and click Next.
On the Select web Listener pane either edit an existing listener or create a new Listener in case no listener exists.

Configure the listener to listen on the External network segment. You can use the Address option to specify the specific external IP address to listen to in case you got multiple external IP addresses.

On the Port Specification page, enable SSL on port 443 and clear "Enable HTTP". Click Select to select the web site certificate that will be used for the client secure connection. If clicking Select results with no certificates, you should either close and reopen the ISA console (it might have been open when you imported the certificate), or re-check the certificate existence in the Personal certificate store of the Local Computer. Click Next and Finish to close the Listener configuration. Back in the Select Web Listener page, click Edit to edit the listener further more.

On the Preferences tab click Authentication.

Remove the Integrated selection, and select the OWA forms-Based instead. Click OK twice to confirm the Listener configuration and return to the Select Web Listener page. Click Next twice to make the rule apply to all users, and click Finish. Back in the ISA console, click Apply to activate the new rule.

Verify External connectivity.

The final step is to make sure that external clients can indeed access the OWA web site. Connect a computer to the Internet, and ping the web site common name. The name should be resolved to the ISA firewall external interface IP address that you specified on the listener. If the name could not be resolved by the public DNS service for your domain, verify that the record was registered with the ISP/DNS service provider. To temporarily overcome the record registration issue, update the client HOSTS file to provide the name-to-IP translation, where the common name translates to the ISA External IP address.
After name resolution is available, open a web browser and connect to the URL, for example: https://owa.liran.org/exchange

Note!
As the Web Publishing rule is configured to answer requests directed specifically to the FQDN in addition to the specific Exchange virtual directories, no other URL entered will allow you to access the OWA site.

Other requests will be answered with the error message: Error Code: 403 Forbidden. The server denied the specified Uniform Resource Locator (URL). Contact the server administrator. (12202)
A successful connection attempt will probably provide with the following Security Alert, as the CA certificate is unknown to the external client.

Disregard this warning, by clicking Yes.
If your users are concerned with this message either install the CA certificate on each remote computer (which might not be possible in every Internet Café in Bangkok), or get yourself a web certificate from a trusted CA.

The users will now be instructed to provide logon information using the form based authentication page provided by the ISA firewall. The transport of the user credentials are encrypted by SSL 128bit encryption.

Voila! We are there. Enjoy your secure Outlook Web access solution.
If you find any faults in this article you are welcome to contact me at: liran.zamir@getronics.com

We hope you enjoyed this article and found something in it that you can apply to your own network. If you have any questions on anything discussed in this article, head on over to http://forums.isaserver.org/ultimatebb.cgi?ubb=get_topic;f=23;t=000106 and post a message. I’ll be informed of your post and will answer your questions ASAP. Thanks! –Tom

If you would like us to email you when Liran Zamir releases another article on ISAserver.org, subscribe to our 'Real-Time Article Update' by clicking here. Please note that we do NOT sell or rent the email addresses belonging to our subscribers; we respect your privacy.

Read more »

Posted in: Active Directory,CA,Exchange,ISA

Automatic Virtual Machine Activation Step by Step

What is AVMA?

Automatic Virtual Machine Activation is a new Windows feature added in Windows Server 2012R2 that enables you to activate your Windows VMs without using a KMS server or even a network connection. As you spin up new virtual machines they will activate against the host Hyper-v server. This activation only lasts 7 days and then it needs to renew it’s activation. This is perfect for your Windows Datacenter Hyper-v hosts because you can

Two features of AVMA that no other activation method offers are:

1. The ability to automatically activate virtual machines without a network connection
2. Track virtual machine licenses from the host virtualization server, without requiring any access rights on the virtualized machine

(Other options for activation are: KMS server, MAK key, AD-based Activation)
How Does AVMA work?
Automatic Virtual Machine Activation requires a Hyper-v host server running Windows Server 2012 R2 Datacenter and it must be activated. The Virtual Machines must be 2012R2 or above to activate under AVMA. This includes 2012R2 Datacenter, Standard, and Essentials.
The guest VMs must have an AVMA product key configured on them. See the table blow for the key.
Windows Server 2012 R2 AVMA keys:

Edition	AVMA key
Datacenter	Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW
Standard	DBGBW-NPF86-BJVTX-K3WKJ-MTB6V
Essentials	K2XGM-NMBT3-2R6Q8-WF2FK-P36R2

* Licenses above were taken from http://technet.microsoft.com/en-us/library/dn303421.aspx
These keys can be installed during the install or installed at a later time.
The last piece of this is how the virtual machine talks to it’s Hyper host to get activated. The channel it uses is the “Data Exchange” that the para-virtualization drivers provide. This is a per VM setting and is enabled by default. You can verify that it is enabled by going into a VMs settings and then selecting the Integration Services. Make sure “Data Exchange” is checked.

AVMA also provides real-time reporting on usage and historical data on the license state of the virtual machine. This data is stored and available on the virtualization host server. There is no need to have any access or rights to the VMs on that server to access this information.
Step by Step directions to implement AVMA:
To use AVMA is easy just follow these 4 steps to virtual bliss:

1. Install Server 2012R2 Datacenter
2. Activate the server
3. Add the Hyper-v Role
4. Install a 2012R2 Virtual Machine and assign an AVMA key

If your virtual machine needs a key or already has a different key and you would like to give it an AVMA key there are a couple ways to achieve that. Here are two:
Using the GUI – Start the File Manager and Right click on “This PC”. From that dropdown list select “Properties”.

You will then get the System Screen. From here you select the Change Product key at the bottom right of the window. Put in one of the keys in the above table.


Another way to change the product key is to do it from a command prompt or script. This will need to run with administrative privileges.
Steps to Set the Product key from a command Prompt:

• Click on the Start Button and type “CMD”   — (Welcome back Start Button)
• Right click on the Command Prompt and select “Run as administrator”
• In the command window run the command slmgr /ipk <AVMA_key>
  Command in the example below:
  slmgr /ipk Y4TGP-NPTV9-HTC2H-7MGQ3-DV4TW

Hope you found this fun and informative! –Brian

---

This post is part of a series of posts by the US IT Pro Evangelist team. In this series we cover, Why Windows Server 2012 R2 is important, how to deploy, manage, configure any number of components in Windows Server 2012 R2. 
This series is deep technical content with lots of How To’s and Step-By-Step instructions. You will learn about storage, cloud integration, RDS, VDI, Hyper-V, virtualization, deduplication, Hyper-v replica, DNS, AD, DHCP, high availability, SMB, backup, PowerShell and much, much more! – See more at: http://itproguru.com/expert/2013/10/windows-server-2012-r2-launch-blog-series-why-win2012r2/

Read more »

Posted in: VMware,Vshare,Windows Server 2012

Create Backups of Virtual Machines in Windows Azure by using PowerShell

Microsoft Scripting Guy, Ed Wilson, is here. Welcome back Keith Mayer as our guest blogger today. This is Part 1 of a two-part series. In Part 2, we’ll restore virtual machines in Windows Azure from these backups.

Keith Mayer is a senior technical evangelist at Microsoft, and he focuses on the Windows infrastructure, datacenter virtualization, systems management, and the private cloud. Keith has over 20 years of experience as a technical leader of complex IT projects, in diverse roles, including network engineer, IT manager, technical instructor, and consultant. He has consulted and trained thousands of IT professionals worldwide on the design and implementation of enterprise technology solutions.

You can find Keith online at http://KeithMayer.com.

Windows Azure Infrastructure Services provides the ability to easily provision or migrate storage, virtual machines, and virtual networks to the global Windows Azure cloud platform by using a cost-effective Pay-As-You-Go model. In my prior Weekend Scripter posts, Getting Started with Windows Azure and PowerShell and Remoting the Cloud with Windows Azure and PowerShell, I provided an introduction to using Windows PowerShell for automated provisioning of Windows Azure cloud fabric resources and workloads running inside virtual machines in Windows Azure.
Once you’ve provisioned a few lab virtual machines on Windows Azure, you’ll likely want to create a backup copy of each virtual machine. This is particularly useful in test lab scenarios, so that you can quickly revert virtual machines back to a known state prior to performing a set of tests.
When you are working in the on-premises world, this is typically performed via virtual machine backup, snapshot, or checkpoint capabilities. In Windows Azure, back up and restore of virtual hard disks can be quickly performed in the cloud with the Windows Azure PowerShell Module by leveraging the Start-AzureStorageBlobCopy cmdlet. However, there’s a bit of work we’ll need to do upfront to capture the information we’ll need for completing this process.
In this post, we’ll step through the process of building a Windows PowerShell script to back up virtual machines in Windows Azure. At the end of this post, I’ve provided a link to the next step, restoring virtual machines in Windows Azure, so that you’ll have the complete end-to-end process.
To back up virtual machines in Windows Azure, we’ll step through the following tasks:

• Select a virtual machine to back up
• Identify each virtual hard disk
• Create a cloud storage container for storing backups
• Back up virtual machines to cloud storage in Windows Azure

Note  To learn more about the basics of Windows Azure Infrastructure Services, you might also be interested in the “Early Experts” Cloud Quest and our scenario-based Cloud Labs step-by-step guides. Both are free online study resources that provide hands-on lab exercises for leveraging Windows Azure and building key IT pro cloud scenarios.

Select virtual machine to back up

The virtual machine you want to back up and restore can be selected by using the Get-AzureVM cmdlet. Running Get-AzureVM alone returns a list of virtual machines that are currently provisioned in Windows Azure.

  Get-AzureVM cmdlet output
To select a particular virtual machine, you can pass the ServiceName and Name values as parameters and set the output to a new Windows PowerShell variable.

  Selecting a Windows Azure virtual machine
Now our selected Windows Azure virtual machine can be referenced by using the variable $vm in the remainder of our script.
To capture a valid backup of each virtual hard disk, we also need to temporarily shut down the virtual machine to a state where the virtual machine is not running, but its configuration is kept in a provisioned state. We can accomplish this with the Stop-AzureVM cmdlet.

  Using Stop-AzureVM with the StayProvisioned parameter
Now that our virtual machine is selected and in the right state, we can proceed to the next step of finding each virtual hard disk we want to back up and restore.

Identify virtual hard disks

Virtual machines in Windows Azure can be provisioned with two general types of virtual hard disks: operating system disks and data disks. Each virtual machine will have one operating system disk from which it boots and runs the operating system. In addition, each virtual machine can have one or more additional data disks on which program code and data files can be stored. To perform a complete virtual machine backup, we’ll need to locate all of the virtual hard disks that our virtual machine is currently using.
To store the location for the operating system disk, we can use the Get-AzureOSDisk cmdlet.

  Locating the virtual machine operating system disk with Get-AzureOSDisk
For any virtual hard disk that we want to back up or restore, the two property values in which we’ll be most interested are the DiskName and MediaLink values, which are shown in the following image. These values provide the information that we’ll need to properly back up and restore each virtual hard disk that is associated with a virtual machine.

  Common property values for a Windows Azure virtual hard disk
To store the location for all data disks, we can use the Get-AzureDataDisk cmdlet. Because virtual machines can be provisioned with multiple data disks, this cmdlet returns of a collection of data virtual hard disks.

  Storing location for data disks with the Get-AzureDataDisk cmdlet

Create cloud storage container for storing backups

Prior to performing a backup, we’ll need to make sure that a container exists in our Windows Azure Storage Account to store these backup copies. First, we’ll need to determine the name of our Windows Azure Storage Account. We can do this by leveraging the MediaLink property of Azure Disks mentioned earlier.

  Determining the name of Windows Azure Storage Account by using MediaLink property
Now that we know the name of our Windows Azure Storage Account, we’ll want to set it as the current storage account for the remainder of our script by using the Set-AzureSubscription cmdlet.

  Setting the current storage account
Next, we can easily check to see if our desired container location for storing backups already exists inside our storage account, and if not, we can quickly create it by using the New-AzureStorageContainer cmdlet.

  Creating a new Windows Azure storage container
We can confirm that the new storage container has been created by using the Get-AzureStorageContainer cmdlet without parameters.

  Confirming creation of storage container with Get-AzureStorageContainer cmdlet
Now, we’re ready to back up our virtual machine!

Back up virtual machines in Windows Azure to cloud storage

To create a backup copy of the operating system disk on our virtual machine, we’ll first set the values for a couple variables that identify the blob and container names for the virtual disk that we want to back up. Then, we’ll use the Start-AzureStorageBlobCopy cmdlet to begin the copy process to our previously defined backup container location.

  Using Start-AzureStorageBlobCopy cmdlet to back up virtual hard disk
It’s important to note that the copy process performed by the Start-AzureStorageBlobCopy cmdlet is asynchronous in nature, and it runs in the background on the Windows Azure platform. To ensure that the copy process has completed before continuing with the next line in a script, we can use the Get-AzureStorageBlobCopyState cmdlet to wait until the copy process is finished.

  Using Get-AzureStorageBlobCopyState to confirm that the copy process completed
To back up our Windows Azure data disks, we’ll use a similar set of cmdlets, but we’ll run them inside a ForEach loop because Windows Azure data disks are returned as a collection.

  Back up data disks by using ForEach loop
After the backup process has completed, use the Get-AzureStorageBlob cmdlet to confirm that a copy of each virtual hard disk now exists in the backup storage container location.

  Using Get-AzureStorageBlob to confirm backup copies
Our backup process is complete, and we can now restart the Windows Azure virtual machine by using the Start-AzureVM cmdlet.

  Using Start-AzureVM to restart virtual machine after back up is complete
Congratulations! But keep learning!
You’ve completed the process for creating cloud backups of virtual machines in Windows Azure with Windows PowerShell! You can use the cmdlets and snippets in this post to quite easily build an automated approach to capture a backup of each Windows Azure virtual machine in your subscription, perhaps on a nightly basis.
In Part 2 of this series, we’ll walk through the process of restoring virtual machines in Windows Azure from these backups so that you can automate the complete end-to-end backup and restore process.

• DO IT! Perform Cloud Restores of Windows Azure Virtual Machines using PowerShell

In addition, you may want to leverage these resources to continue your learning about Windows Azure Infrastructure Services:

• “Early Experts” Cloud Quest: Build a virtual network environment for Windows Server 2012 with multiple virtual machines in the cloud on Windows Azure!
• Windows Azure Cloud Labs: Build key IT pro scenarios in the cloud by using Windows Azure Infrastructure Services!
• Windows Azure PowerShell Module Tutorials: Complete these advanced tutorials about using the Windows Azure PowerShell Module to manage virtual machines and virtual machine images!

Thank you, Keith, for sharing your time and knowledge.
I invite you to follow me on Twitter and Facebook. If you have any questions, send email to me at scripter@microsoft.com, or post your questions on the Official Scripting Guys Forum. See you tomorrow. Until then, peace.

Ed Wilson, Microsoft Scripting Guy

Read more »

Posted in: VMware

Sao lưu: Incremental hay Differential?

Một số các bạn có thói quan sao lưu dữ liệu (backup) – vậy thì quá tốt – bởi vì tôi đã gặp rất nhiều người hỏi cùng 1 câu hỏi: làm sao cứu dữ liệu của tôi – 80% đã quá trễ, 20% tốn từ 2tr đến 4tr để cứu những gì có thể cứu được. Do vậy, “backup or die”.
Các bạn nếu có dùng phần mềm backup sẽ hay nghe nói phần mềm này rất chuyên nghiệp, có tính năng backup “Incremental” và “Differential”. Vậy thì 2 thuật ngữ này là gì?
Về cơ bản, có 3 phương pháp backup: Full, Differential, và Incremental.
1. Full backup
Tên như người – nghĩa là backup tất cả
Ví dụ minh họa:

• Bạn có 1 file text A.txt nội dung là 1 2 3 4
• Bạn cấu hình Full backup hằng ngày vào buổi tối – phần mềm backup sẽ sao lưu y chang File đó mỗi ngày

Lợi điểm:

• Dễ phục hồi dữ liệu (restore).

Ví dụ minh họa như trên:
Giả sử bạn cần phục hồi dữ liệu về thời điểm Thứ Bảy: Bạn chỉ cần 1 bản Full backup của tối Thứ Bảy
Bất lợi:

• Tốn thời gian và dung lượng backup.

Tưởng tượng bạn có 10TB dữ liệu – mỗi bản Full backup lại 10TB nữa, 1 tuần backup mất 70TB – quá nhiều.
Trong thực tế, không áp dụng Full backup hằng ngày cho khối lượng dữ liệu lớn.
2. Differential backup
Backup những gì thay đổi so với lần Full backup gần nhất

Ví dụ minh họa:

• File text A.txt có nội dung 1 2 3 4
• Cấu hình backup: Full backup vào Chủ Nhật, Differential backup vào Thứ Hai, Thứ Ba, Thứ Tư, Thứ Năm, Thứ Sáu, và Thứ Bảy.

Giả sử Thứ Hai bạn sửa nội dung A.txt thành 1 2 3 4 5 –> Differential backup sẽ chỉ sao lưu phần thay đổi: 5
Giả sử Thứ Ba bạn sửa nội dung A.txt thành 1 2 3 4 5 6 –> Differential backup sẽ chỉ sao lưu phần thay đổi: 5 6
Lợi điểm:

• Tiết kiệm thời gian và dung lượng backup.
• Restore nhanh hơn so với Full backup

Bất lợi:

• Restore cần đủ file: 1 File Full backup lần gần nhất và 1 File Differential backup vào thời điểm cần restore

Ví dụ minh họa nêu trên:
Giả sử bạn cần restore file về thời điểm Thứ Ba – bạn cần có file Full Backup của Chủ Nhật và Differential backup của Thứ Ba
3. Incremental backup
Backup những gì thay đổi so với lần Incremental backup gần nhất

Ví dụ minh họa:

• File text A.txt có nội dung 1 2 3 4
• Cấu hình backup: Full backup vào Chủ Nhật, Incremental backup vào Thứ Hai, Thứ Ba, Thứ Tư, Thứ Năm, Thứ Sáu, và Thứ Bảy.

Giả sử Thứ Hai bạn sửa nội dung A.txt thành 1 2 3 4 5–> Incremental backup sẽ chỉ sao lưu phần thay đổi: 5
Giả sử Thứ Ba bạn sửa nội dung A.txt thành 1 2 3 4 5 6 –> Incremental backup sẽ chỉ sao lưu phần thay đổi: 6
Lợi điểm:

• Tốn ít thời gian và dung lượng sao lưu nhất.

Bất lợi:

• Restore cần đủ file: 1 File Full backup lần gần nhất và tất cả các File Incremental backup từ thời điểm Full backup đến thời điểm cần restore
• Restore lâu hơn so với Differential Backup.

Ví dụ minh họa nêu trên:
Giả sử bạn cần restore file về thời điểm Thứ Ba – bạn cần có file Full Backup của Chủ Nhật và Incremental backup của Thứ Hai và Incremental backup của Thứ Ba
Trong thực tế, cấu hình backup phổ biến nhất là:

• Full Backup hàng tháng.
• Differential Backup hàng tuần.
• Incremental Backup hàng ngày.

Chúc các bạn luôn an toàn trên xa lộ thông tin :).

Read more »

Posted in: Backup

SBS 2008 Using the POP Connector

To access the Windows Small Business Server POP3 Connector properties

1. Open the Windows SBS Console.
   
2. On the navigation bar, click Network.
   
3. Click the Connectivity tab.
   The list view displays information about your network connections.
   
4. In the list view, click POP3 Connector.
   
5. In the Tasks pane, click View POP3 Connector properties.
   

To view error messages for the POP3 Connector

1. Click Start, type eventvwr, and then press ENTER.
   
2. In the console tree, expand Applications and Service Logs.
   
3. Expand Windows Small Business Server 2008, and then select Microsoft Windows Small Business Server/Operational.
   The details pane displays error and event messages for Windows SBS 2008 including error messages from the POP3 Connector.
   

Read more »

Posted in: Exchange

Link to original Microsoft article:
http://support.microsoft.com/kb/912375/

How to increase the Exchange Server 2003 Service Pack 2 database size limit

To increase the Exchange Server 2003 SP2 database size, follow these steps.

Important Before you increase the maximum size of an Exchange database, verify that sufficient hard disk space is available for the larger database.

1. On the computer that is running Exchange 2003 SP2, click Start, click Run, type regedit, and then click OK.
2. Click one of the following registry subkeys, as appropriate for the store that you want to increase:
   • For a mailbox store, click the following registry subkey:
     HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\Server name\Private-Mailbox Store GUID
   • For a public folder store, click the following registry subkey:
     HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeIS\Server name\Public-Public Store GUID
3. On the Edit menu, point to New, and then click DWORD Value.
4. In the New Value #1 box, type Database Size Limit in Gb, and then press ENTER.
5. Right-click Database Size Limit in Gb, and then click Modify.
6. Click Decimal, and then type an integer from 1 to 75 in the Value data box.
   
   Note These integer values represent the maximum size of the database in gigabytes (GB). For example, a value of 75 represents a database that has a maximum size of 75 GB.
7. Click OK, and then exit Registry Editor.
8. Restart the Microsoft Exchange Information Store service. To do this, follow these steps:
   1. Click Start, click Run, type cmd, and then click OK.
   2. At the command prompt, type the following command, and then press ENTER:
      net stop msexchangeis
   3. After the Microsoft Exchange Information Store service has stopped successfully, type the following command, and then press ENTER:
      net start msexchangeis
9. Examine the Application log to verify that the database size has been set successfully. To do this, follow these steps:
   1. Click Start, click Run, type eventvwr, and then click OK.
   2. In the Event Viewer tool, click Application.
   3. Double-click event ID 1216 to verify that the database size has been set successfully.

To determine if you're running Exchange Server 2003 SP2:

1. Open Exchange System Manager
2. Expand 'Servers'
3. Right-click on [server name], choose Properties
4. On the General tab, verify that the version is Version 6.5 (Build 7638.2: Service Pack 2)

Read more »

Fix Outlook 2007 Certificate Errors

For SBS 2008 run the following commands in Exchange Management Shell:

Set-ClientAccessServer -Identity yourserver -AutodiscoverServiceInternalUri https://external.yourdomain.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “yourserver\EWS (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “yourserver\oab (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/oab
Set-UMVirtualDirectory -Identity “yourserver\unifiedmessaging (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/unifiedmessaging/service.asmx

For Exchange 2007 Standard or Enterprise on Windows Server 2008 run the following commands in Exchange Management Shell:
Set-ClientAccessServer -Identity yourserver -AutodiscoverServiceInternalUri https://external.yourdomain.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “yourserver\EWS (Default Web Site)” -InternalUrl https://external.yourdomain.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “yourserver\oab (Default Web Site)” -InternalUrl https://external.yourdomain.com/oab
Set-UMVirtualDirectory -Identity “yourserver\unifiedmessaging (Default Web Site)” -InternalUrl https://external.yourdomain.com/unifiedmessaging/service.asmx
If you’re not sure which set of commands to use, type Get-WebServicesVirtualDirectory in Exchange Management Shell and see what is listed for name. You will either see EWS (SBS Web Applications) or EWS (Default Web Site). Match that up with the command set above and it should find the appropriate virtual directories.
On Windows Server 2008, if you see access denied errors then make sure you use Run As Administrator to run Exchange Management Shell.

Read more »

Posted in: Exchange,Outlook

Exchange 2007 Autodiscover Issues

We have recently begun installing a lot of Exchange 2007 servers, both Exchange 2007 standard and as part of SBS 2008. Starting with Exchange 2003 there is a lot of reliance on the web services part of the server which reside in IIS. In order to get things working properly we get a SSL certificate, usually from GoDaddy, to secure the exchange directories. This allows us to set up devices with Exchange Activesync, OWA without certificate warnings, and Outlook Anywhere.
We’ve noticed that when installing these certificates, Outlook clients on the domain begin to see a certificate error. This is because of the Autodiscover URLs that are part of Exchange server and the fact they no longer match the self-signed certificate that Exchange produces on installation.
In order to update those URLs you need to use Exchange Management Shell to run some commands. The commands are different for SBS installations and Standard installations. In the following commands, replace yourserver with the netbios name of your Exchange server and external.yourdomain.com with the external address of your server.
For SBS 2008 run the following commands in Exchange Management Shell:
Set-ClientAccessServer -Identity yourserver -AutodiscoverServiceInternalUri https://external.yourdomain.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “yourserver\EWS (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “yourserver\oab (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/oab
Set-UMVirtualDirectory -Identity “yourserver\unifiedmessaging (SBS Web Applications)” -InternalUrl https://external.yourdomain.com/unifiedmessaging/service.asmx
For Exchange 2007 Standard or Enterprise on Windows Server 2008 run the following commands in Exchange Management Shell:
Set-ClientAccessServer -Identity yourserver -AutodiscoverServiceInternalUri https://external.yourdomain.com/autodiscover/autodiscover.xml
Set-WebServicesVirtualDirectory -Identity “yourserver\EWS (Default Web Site)” -InternalUrl https://external.yourdomain.com/ews/exchange.asmx
Set-OABVirtualDirectory -Identity “yourserver\oab (Default Web Site)” -InternalUrl https://external.yourdomain.com/oab
Set-UMVirtualDirectory -Identity “yourserver\unifiedmessaging (Default Web Site)” -InternalUrl https://external.yourdomain.com/unifiedmessaging/service.asmx
If you’re not sure which set of commands to use, type Get-WebServicesVirtualDirectory in Exchange Management Shell and see what is listed for name. You will either see EWS (SBS Web Applications) or EWS (Default Web Site). Match that up with the command set above and it should find the appropriate virtual directories.
On Windows Server 2008, if you see access denied errors then make sure you use Run As Administrator to run Exchange Management Shell.
At this point, we have solved problems with Autodiscover that resulted in error messages in Outlook clients but have not actually set up Autodiscover. The Autodiscover setup process usually includes setting up a new site in IIS for autodiscover.yourdomain.com and adding the autodiscover virtual directory to it. You’ll also need a SSL cert for it which is why we don’t usually set it up. We have yet to see any advantages to setting up Autodiscover since our clients usually don’t have that many clients connected to their Exchange server.

Read more »

Posted in: Exchange

Exchange - Build Numbers and Release Dates

Version                          Build number              Release date

Server  4.0                      4.0.837                   April 1996

Server  4.0 (a)                  4.0.993                   August 1996

Server  4.0 SP1                  4.0.838                   May 1996

Server  4.0 SP2                  4.0.993                   August 1996

Server  4.0 SP3                  4.0.994                   November 1996

Server  4.0 SP4                  4.0.995                   April 1997

Server  4.0 SP5                  4.0.996                   May 1998

Server  5.0                      5.0.1457                  March 1997

Server  5.0 SP1                  5.0.1458                  June 1997

Server  5.0 SP2                  5.0.1460                  February 1998

Server  5.5                      5.5.1960                  November 1997

Server  5.5 SP1                  5.5.2232                  July 1998

Server  5.5 SP2                  5.5.2448                  December 1998

Server  5.5 SP3                  5.5.2650                  September 1999

Server  5.5 SP4                  5.5.2653                  November 2000

2000 Server                      6.0.4417                  October 2000

2000 Server (a)                  6.0.4417                  January 2001

2000 Server SP1                  6.0.4712                  July 2001

2000 Server SP2                  6.0.5762                  December 2001

2000 Server SP3                  6.0.6249                  August 2002

2000 Server post-SP3             6.0.6487                  September 2003

2000 Server post-SP3             6.0.6556                  April 2004

2000 Server post-SP3             6.0.6603                  August 2004

Server  2003                     6.5.6944                  October 2003

Server  2003 SP1                 6.5.7226                  May 2004

Server  2003 SP2                 6.5.7638                  October 2005

Server  2007                     8.0.685.24 or 8.0.685.25  December 2006

Server  2007 SP1                 8.1.0240.006              November 2007

Read more »

Changing SBS 2008 Exchange Mailbox Limits

In Windows SBS 2008, the mailbox database and the individual mailboxes have a size limit of 2 GB. If the size limit of the mailbox database or the individual mailboxes on the Source Server is more than 2 GB, you must manually change the size limits on the Destination Server

To change the size limit of the mailbox database

1. On the Destination Server, click Start, click All Programs, click Microsoft Exchange Server 2007, and then click Exchange Management Console.
   
2. Click Continue in the User Account Control dialog box.
   
3. In the Exchange Management Console navigation pane, expand the Server Configuration node, and then click Mailbox.
   
4. In the result pane, click the Destination Server name.
   
5. In the work pane, right-click Mailbox Database, and then click Properties.
   
6. Click the Limits tab, specify the mailbox database limits, and then click OK.
   

To change the size limit of the individual mailboxes

1. On the Destination Server, open the Windows SBS Console.
   
2. In the navigation bar, click the Users and Groups tab, and then click Users.
   
3. Click a user account, and then click Edit user account properties.
   
4. Click the E-Mail tab, update the maximum mailbox size information, and then click OK.
   
5. Repeat steps 3 and 4 until all user accounts are updated.
   

Read more »

Posted in: Exchange