Download the Image Resizer Powertoy Clone for Windows 7 / Server 2008 R2

One thing lacking in Windows 7 and Windows Server 2008 R2 is a native picture resizing tool.  I find this surprising since Windows 7 is chock full of image and video eye-candy.

Thankfully, there's an easy to install image resizer for all versions of Windows available on Codeplex.com.  The tool is available in both 32-bit and 64-bit versions.  Image Resizer 2.1 allows you to resize any image by simply right-clicking the image(s) and selecting Resize from the context menu, as shown.

Then you can choose the size and options for the pictures, as shown.

You can perform bulk resizing by selecting more than one photo and resize them.  Can't get much easier than that!

Read more ...

How to Use the Windows Mobile 6.1 Device Emulator

The Windows Mobile 6.1 Emulator is a software version of a Windows Mobile phone that you can use to test Windows Mobile applications, such as Exchange ActiveSync.  This tool is enormously helpful for testing, troubleshooting, and creating documentation.

The WM emulator has been around since about 1998, but disappeared for a while, due to some legal issues.  I remember using this tool at TechEd a few years ago in a session that taught you how to create applications for Windows Mobile.  It's back now, with improved functionality and ease of use.

The emulator runs on top of Microsoft Virtual PC 2007 (a free download).  Virtual PC 2007 provides the hooks to the host operating system to provide network access and resource sharing.  This makes the emulator much simpler to configure than in the past.

You will need to download the following two packages from Microsoft:

• Virtual PC 2007 (32 or 64-bit, 30.5MB)
• Windows Mobile 6.1 Emulator Images (Standard 185MB or Professional 272MB)

Install Virtual PC 2007 first, accepting all the defaults in the setup wizard.  No further configuration of Virtual PC 2007 is required.

Next, install Windows Mobile 6.1. Emulator Images, accepting all the defaults in the setup wizard.

To configure the emulator, run it from Start > All Programs > Windows Mobile 6 SDK > Standalone Emulator Images > US English > WM 6.1 Professional.  Click File > Configure.  On the General tab, browse to your Desktop as the Shared Folder.  This will make your Desktop the external storage card on the emulator.  Now check the Network tab and check Enable NE2000 PCMCIA network adapter and bind to checkbox and click OK.  By now the emulator should have finish starting up. 

Use your mouse to configure a network connection on the emulator, as follows:

• Click Start > Settings on the emulator.
• Click the Connections tab and Connections.
• Click the Advanced tab and Select Networks.
• Select My Work Network in the top dropdown box
• If you use a proxy server to access the Internet click Edit.  Click the Proxy Settings tab, configure your proxy settings.  Use the Advanced button to configure the proxy port, user name, password, and domain.  Click OK to get back to Network Management.
• Click OK to return to Settings.
• Click Network Cards.
• In the My network card connects to dropdown box select Work
• Click NE2000 Compatible Ethernet Driver.  Check to see that the NE2000 Ethernet Driver has received an IP address from your DHCP server, or configure the IP address and name servers here.  Click OK twice to return to Settings.
• Close Settings.

Now test your Internet connectivity by clicking Start > Internet Explorer.  Enter www.microsoft.com, which will redirect to mobile.microsoft.com, as shown.

You can now use the WM 6.1 emulator just like a real hardware mobile device!  Use it to test Exchange ActiveSync, your company's AutoDiscover record, or your custom applications.  The emulator runs the exact same code that Microsoft offers to device manufacturers.

There are several Windows Mobile 6.1 Professional (touchscreen PocketPC) emulator images:

• WM 6.1 Classic
• WM 6.1 Professional (used in the screenshots above)
• WM 6.1 Professional 240x240
• WM 6.1 Professional 480x480
• WM 6.1 Professional Square
• WM 6.1 Professional Square QVGA
• WM 6.1 Professional Square VGA
• WM 6.1 Professional VGA

The Windows Mobile 6.1 Standard (non-touchscreen SmartPhone) emulator images include:

• WM 6.1 Standard (shown below)
• WM 6.1 Standard 400x240
• WM 6.1 Standard 440x240
• WM 6.1 Standard Landscape
• WM 6.1 Standard QVGA
• WM 6.1 Standard Square

Read more ...

How to Securely Deploy iPhones with Exchange ActiveSync - Phase 2 - Configuring ActiveSync and Active Directory

This is the third post in my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. To read an overview of the solution click here. In this phase, we will configure ActiveSync on the Exchange CAS and Mailbox servers and make the necessary changes in Active Directory.

Securing Exchange ActiveSync
Exchange ActiveSync is enabled by default for all Exchange users in a normal installation.  It can be disabled for select users using Active Directory Users and Computers (ADUC) for Exchange 2003 users or the Exchange 2007/2010 management tools for those mailbox users.

Since our solution requires that ActiveSync be available for only specific users, we could use a script that disables Activesync for all users who are not a member of an ActiveSync Users security group.  While this would work, it would be clumsy and new users could access ActiveSync until the script runs again.  It also wouldn't solve the requirement that only authorized devices can access ActiveSync.

In order to fulfill the requirements that only authorized users can access ActiveSync using authorized devices, we will configure ActiveSync to require user certificates.  The iPhones will receive a unique iPhone Configuration Profile that includes the user certificate we generated in Phase 1.  That profile can be loaded on one, and only one, iPhone.  More on that in a later phase.

Configuring Exchange ActiveSync
As mentioned earlier, ActiveSync is enabled by default in a normal Exchange installation.  It is configured by default to use only Basic authentication.  We need to configure the CAS servers to require user certificates.  This is only configured on the CAS servers, not the Mailbox servers.

To do this using the Exchange Management Console (EMC), expand Microsoft Exchange > Server Configuration > Client Access.  Select the Client Access Server to configure and click the Exchange ActiveSync tab in the work pane.  Double-click Microsoft-Server-ActiveSync to view its properties.  Click the Authentication tab and select Require client certificates, as shown below.

Repeat these steps for each CAS server.

To do the same thing using the Exchange Management Shell (EMS), use the following cmdlet to require client certificates for each CAS server:

Set-ActiveSyncVirtualDirectory -identity "CASservername\Microsoft-Server-ActiveSync (Default Web Site)" -ClientCertAuth Required

Finally, we need to make an adjustment to the uploadReadAheadSize value in the IIS metabase.  This is required when you use certificate-based authentication.  Run the following commands from a CMD prompt on the CAS server, replacing the value in quotes with the maximum message size (in bytes) allowed by your organization.

C:\Windows\System32\inetsrv\appcmd.exe set config -section:system.webServer/serverRuntime /uploadReadAheadSize:"10485760" /commit:apphost

C:\Windows\System32\inetsrv\appcmd.exe set config "Default Web Site" -section:system.webServer/serverRuntime /uploadReadAheadSize:"10485760" /commit:apphost

The commands above set uploadReadAheadSize to 10MB (the default is 48KB).  1024 * 1024 * 10 = 10MB.  You then need to restart the IISAdmin service to affect the change.

That's all there is to it. You may also want to configure Remote File Servers at this time, but I won't be covering that in this series.

A Note About Exchange 2003 Mailbox Servers
I mentioned in the introduction that this scenario has some Exchange 2003 mailbox servers, just to spice things up.  If you use Exchange 2007 or 2010 CAS servers to front-end ActiveSync for Exchange 2003 mailboxes, you need to configure ActiveSync on the Exchange 2003 mailbox servers to allow Integrated Windows Authentication.  This is because the Exchange 2007/2010 CAS servers use Kerberos pass-through authentication to the E2K3 mailbox servers.

The trouble is, you can't configure this using Exchange ESM and if you try to modify the Microsoft-Server-ActiveSync virtual directory in IIS Manager, the Exchange DS2MB process will overwrite your changes in a few minutes.  This is detailed on the Exchange Team blog here.

To overcome this, download and install Microsoft KB 937031.  The hotfix normally does not require a reboot, but will prompt for one if a scheduled reboot has been deferred.  This hotfix will enable the Authentication button on the Access tab of the Microsoft-Server-ActiveSync object.  This object is found in ESM under Servers > servername > Protocols > HTTP > Exchange Virtual Server > Microsoft-Server-ActiveSync.  Simply enable Basic authentication and Integrated Windows Authentication, as shown.

Configuring Active Directory

Now we need to configure Active Directory for the solution by creating the necessary user groups and publishing the self-signed CA Root certificate.

Create Security Groups

Create two universal security groups, ActiveSync Users and ActiveSync Admins.  Populate the groups with the appropriate users.  By using security groups, we can easily manage the solution using roles based security.

Configure Group Policy

Since our root CA is is not trusted by an external trusted CA like VeriSign or Entrust, we need to install the root certificate in the Trusted Root Certification Authorities certificate store on the Exchange CAS servers.  While we can do this manually using the Certificates MMC, I'm going to show you how to publish it to all computers in AD using Group Policy, which is my best practice.

Using appropriate credentials (usually Domain Admin), open the Group Policy Management Console (GPMC).  Edit the Default Domain Policy and navigate to Computer Configuration > Policies > Windows Settings > Security Settings > Public Key Policies > Trusted Root Certification Authorities, as show below.

Right-click Trusted Root Certification Authorities and select Import.  Run through the Certificate Import Wizard to import the RootCA.cer certificate file we exported at the end of Phase 1.  Be sure to place the certificate in the Trusted Root Certification Authorities store.  You should now see the certificate in the Default Domain Policy.

After AD replication completes, logon to a CAS server and run GPUpdate to refresh Group Policy and import the root certificate.  Confirm that the certificate is installed using Internet Explorer.  Click Tools > Internet Options > Content > Certificates.  The root certificate should show under the Trusted Root Certification Authorities tab, as shown.

We have completed securing and configuring Exchange ActiveSync, and configured Active Directory by creating the necessary groups and importing the root certificate into the Default Domain Group Policy.

---

This concludes Phase 2 of my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise. The next phase will cover how to publish the user certificates to user accounts who are members of the ActiveSync Users security group.

Other articles in this series:

• How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise
• Phase 1 - Building the CA
• Phase 2 - Configuring ActiveSync and Active Directory
• Phase 3 - Publishing User Certificates to Active Directory
• Phase 4 - Creating the iPhone Configuration Profile
• Phase 5 - Creating the Web Site for iPhone Profile Deployment
• Phase 6 - End-User Deployment of the ActiveSync Profile

Read more ...

Get Certified at TechEd 2010 North America

Special news for TechEd 2010 North America attendees!

Pre-register to take a certification exam at Tech·Ed before June 5, and take advantage of special exam fee discount offers:

• 50% off the regular price of $125 – a $62.50 savings!
• Sign up to take multiple exams while at TechEd and receive a volume discount

Pre-registration details will be available soon on the new TechEd certification web site, http://northamerica.msteched.com/certification

Get your geek on and get studying!

Read more ...

How to Securely Deploy iPhones with Exchange ActiveSync - Phase 1 - Building the CA

This is the second post in my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise.  To read an overview of the solution click here.  In this phase, we will create a new certificate server and generate the user certificate that will be used for ActiveSync authentication.  This single certificate will be installed on iPhones and published in Active Directory.

If your organization already has a certificate server, you can use it to create a user certificate, as specified later in this article.  In this soup-to-nuts series I will explain how to create a new stand-alone Windows Server 2008 R2 CA (Certification Authority) for this purpose.

Build a Windows 2008 R2 Certificate Server

Begin configuring the Windows Server 2008 R2 server by installing the Active Directory Certificate Services role.  This can be a new, single-purpose server or one already deployed in your organization.  Contrary to the role name, this is the role to install even if the server is not a member of an Active Directory domain (a workgroup server).  Select the following Role Services when installing the ADCS role:

• Certification Authority
• Certification Authority Web Enrollment (this will also install Web Server (IIS) and all necessary components)

If the server is a member of a domain, you can choose whether to install the CA as an Enterprise or Standalone (non-domain based) CA.  For our purposes, it really doesn't matter which one you choose.  However, if you're planning out a full PKI (which I highly recommend) you should select the CA type that's appropriate for your organization.  For this article, we'll make it a standalone Root CA.

Create a new private key and use the default cryptographic service provider (CSP) and key length (2048).  Supply a common name for the CA, such as W2K8R2-CA.  Note that the default validity period for certificates generated by a Windows Server 2008 R2 CA is 5 years.  Set this value for as long as you'd like.  Consider the fact that the certificate will have to be replaced on the iPhone and in AD when it expires.  I set my validity to 10 years.

Continue through the Add Roles Wizard, accepting all the default settings.  Note that the name and domain settings of the server cannot be changed after Certification Authority has been installed.  Click Install to complete the installation.  No reboot is required, but it is recommended that you run a Windows Update to ensure that the binaries are up to date.

Configure the Certification Authority to Use SSL
In order to request certificates using the web interface, you must enable SSL on the CA's web server.  Open Internet Information Services (IIS) Manager in Administrative Tools.  Select the server name and open the Server Certificates feature.  Select Create Self-Signed Certificate in the Actions pane and supply a friendly name for the certificate, such as "CA Server".

Next, expand Sites and select the Default Web Site.  Click Bindings in the Actions pane and add HTTPS, using the new self-signed certificate, as shown below.

Now select the CertSrv virtual directory under Default Web Site and open the SSL Settings feature.  Select Require SSL and click Apply.

A Word About Certificate Revocation

Certificates can be revoked by the CA Administrator.  When the certificate is revoked, it can no longer be used for its intended purpose.  A revoked certificate is added to the Certificate Revocation List (CRL) which is usually hosted on the CA server.

---

Important - When ActiveSync uses client certificates, Exchange ActiveSync 2007/2010 requires confirmation from the CA that the user certificate has not been revoked.  This happens before Basic authentication is attempted.  If the CRL is not available, ActiveSync will assume that the certificate has been revoked and the user will not be able to use ActiveSync.  You must ensure the CRL (typically, the CA server) is always online and available.  For this reason, I recommend virtualizing the CA to provide greater flexibility.

---

Unless you configure the Online Responder role service which uses the Online Certificate Status Protocol (OCSP), the CA will use a Certificate Revocation List (CRL) to obtain the revocation status of the X.509 user certificate.

OCSP has replaced the traditional CRL file used in the past. It performs much better and has a lower network cost. Complete details about OCSP can be read here.  For the purposes of this article (and brevity), we'll be using a CRL, which requires no further configuration.

Generate a User Certificate
Now we are ready to generate a user certificate from the certificate server.  This is a two-step process where a request is submitted and then approved, creating the certificate and its private key.

Requesting the User Certificate
You make the certificate request using Internet Explorer directly from the CA.  Go to https://servername/certsrv and click Request a certificate.

Click Advanced certificate request and then Create and submit a request to this CA.  Click Yes to the Web Access Confirmation warning to allow the website to perform a digital certificate operation on your behalf.  Complete the certificate request as shown, using your organization's information.

Note: Some reverse proxy servers and firewalls do not allow spaces or special characters in the certificate name or friendly name.  For this reason, I recommend using a simple short name for the user certificate to prevent problems.

Once you submit the certificate request, it must be issued by the CA administrator (probably you).  To issue the certificate, expand the Active Directory Certificate Services role in Server Manager > CA server name > Pending Requests.  Right-click the pending request ID and select All Tasks > Issue to issue the certificate.

Now you need to install the new user certificate using the ADCS website.  Click View the status of a pending certificate request from the Home page and then click the certificate request you generated earlier, as shown below.

Click Yes to the Web Access Confirmation warning to allow the website to perform a digital certificate operation on your behalf and then click Install this certificate.

The user certificate and private key will be installed in the user's (your) Personal certificates store.  It now needs to be exported, both with and without the private key.  The certificate with the private key will be imported into the iPhone and the other will be published to the user account in Active Directory.

Exporting the Certificates

In Internet Explorer, click Tools > Internet Options > Content > Certificates.  You will see the new user certificate in your Personal certificate store.  Select the certificate and click Export.  Follow the default settings in the Certificate Export Wizard, but make sure you select Yes, export the private key and Include all certificates in the certification path if possible.  Supply a password for the certificate.  You will need this password to import the certificate for other Mobile Messaging Administrators in the future.  Browse to the folder of your choice and name the file ActiveSyncUser.pfx.

Now export the user certificate again, this time choosing No, do not export the private key.  Browse to the folder of your choice and name the file ActiveSyncUser.cer.  This certificate will be published later to the ActiveSync user accounts in Active Directory.

Lastly, we need to export the CA's root certificate.  This will be imported into the Trusted Root Certification Authorities certificate store on the Exchange CAS servers so they can trust the user certificate, since it's self-signed.  Click the Intermediate Certification Authorities tab and select the CA's certificate, as shown below.

Click Export and follow the Certificate Export Wizard, selecting all the defaults.  Browse to the folder of your choice and name the file RootCA.cer.

We now have a working CA server, a user certificate with and without the private key, and the Root CA certificate.

---

This concludes Phase 1 of my series, How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise - Phase 1 - Building the CA.  The next phase will cover how to configure the Exchange Client Access Servers for ActiveSync using client certificates.

Other articles in this series:

• How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise
• Phase 1 - Building the CA
• Phase 2 - Configuring ActiveSync and Active Directory
• Phase 3 - Publishing User Certificates to Active Directory
• Phase 4 - Creating the iPhone Configuration Profile
• Phase 5 - Creating the Web Site for iPhone Profile Deployment
• Phase 6 - End-User Deployment of the ActiveSync Profile

Read more ...

How to Securely Deploy iPhones with Exchange ActiveSync in the Enterprise

I've been working on a solution for quite a while to securely deploy iPhones in the enterprise.  

This solution should work exactly the same way on the Apple iPad and should port over fairly easy to the Droid and other non-Microsoft ActiveSync-enabled phones, with some minor changes.

---

Update: I've tested these procedures on iPhone OS4 and everything works as expected. No changes need to be made to the existing procedures - it all works fine.

---

I'll be writing a 7 part series of articles that document all the steps. I'm sure there are other ways to do this, but I can assure you, none of them are documented. (Hint to Apple: This is not documentation, and neither is the iPhone Enterprise Deployment Guide.)

In the scenario I'll be documenting, the customer wants to configure Exchange ActiveSync to provide mobile access to email, calendars and contacts for iPhone users.  To make it more challenging (and slightly more complicated), the customer has Exchange 2003 mailbox servers with Exchange 2007 or 2010 Client Access Servers.

The requirements for deployment are such:

• Only authorized ActiveSync users can access their Exchange email, contacts and calendars
• Only authorized devices (iPhone 3GS or better, iPads) are allowed to use Exchange ActiveSync
• Ability for users to configure/reconfigure ActiveSync for their iPhones over the air
• Information stored on the iPhone must be encrypted
• Capability to remotely wipe iPhones in the event of a security breach (wipes performed by end user or authorized administrator)
• Easy roles-based administration

Summary of the Solution
ActiveSync will be configured to use Basic Authentication over SSL and require client certificates. An iPhone configuration profile will be created and "married" to each iPhone, preventing it from being used on any other iPhone than the one it is configured for. The profile will include the user certificate and its private key.  ActiveSync policies will be used to configure the iPhone to comply with corporate security policies.

The next step is to publish the same user certificate to each ActiveSync user in Active Directory. This will be used to enable certificate-based authentication for ActiveSync. I'll list a few ways that this can be done programmatically via scripts.

Finally, the user needs a way to install the profile. This will be done using a website that the user will open using Safari from the iPhone.

The solution requires a certificate of authority (CA) server that can generate a single user certificate. The CA can be an internal stand-alone or ADCS CA server. I prefer Windows Server 2008 R2 ADCS for the CA, but any CA will do.

More to Come...
I'll break each of these steps down in separate phases. There's a fair amount of detail in each step and I'll include troubleshooting and gotchas as I go through it, but this has worked out be a secure and easy to manage solution.

---

Articles in this series:

• Phase 1 - Building the ADCS server and Generating Certificates
• Phase 2 - Configuring ActiveSync and Active Directory
• Phase 3 - Publishing User Certificates to Active Directory
• Phase 4 - Creating the iPhone Configuration Profile
• Phase 5 - Creating the Web Site for iPhone Profile Deployment
• Phase 6 - End-User Deployment of the ActiveSync Profile

I've also created a complete PDF document version of all the phases here.

Read more ...

The (Nearly) Final TechEd 2010 Bag

Here's a photo of the almost final version of the bag for TechEd 2010.

Looks fairly stylish, if a bit narrow, but I like the neon green accents as long as they don't over-do it.  Let's hope that water bottle on the side doesn't contain chemicals known to the state of Louisiana to contain carcinogens.

Thanks to Rob Nicolai for the preview!

What do you think?  Post a comment below.

Oh, and congratulations to the Saints!  I'm sure New Orleans will celebrating their Super Bowl victory when we get there in June.

Read more ...

Allowing a Service Account to Manage Its Own Service Principal Name (SPN)

As a best practice, Microsoft recommends that SQL Server be run using a domain account. This account is sometimes referred to as the SQL service account. However, when you configure SQL with a domain account you will get an event in the SQL Logs:

The SQL Server Network Interface library could not register the Service Principal Name (SPN) for the SQL Server service. Error: 0x2098, state: 15. Failure to register an SPN may cause integrated authentication to fall back to NTLM instead of Kerberos. This is an informational message. Further action is only required if Kerberos authentication is required by authentication policies.

Doing a Google or Bing Search takes you to multiple MSDN articles that have you running SETSPN to assign the SPN to the domain account that SQL server is using. This can be time consuming and subject to typos and other errors. If you don't set the SPN properly, Kerberos Authentication will not work and that stops pass through authentication from working.  See this article from the Microsoft SQL Server Protocols team for more information.

A simple and easier way to fix this is by using Active Directory Users and Computers to assign the Write Public Information permission to Self on the domain account that SQL is using, as shown below:

If you do this before installing SQL, no restarts are needed. If SQL Server is already running then you will need to restart SQL Server.

After applying this fix you will find the following event in the SQL Logs:

The SQL Server Network Interface library successfully registered the Service Principal Name (SPN) [ MSSQLSvc/servername.domain.com ] for the SQL Server service.

This will allow SQL to register the SPN on start up, and un-register the SPN on shutdown. It also helps when you remove a SQL server from the domain, in that when you shutdown SQL the SPN is unregistered, thus helping to keep your AD database cleaner.

You can also apply this method to other services that use a SPN and you are using a domain service account to run that service.

Special thanks to my colleague, Rick Romack, at Convergent Computing for this tip!

Read more ...

View the TechEd 2010 Mobile Site

The Microsoft TechEd Team has created a TechEd mobile site designed in three versions to best suit your mobile device.

Large screen site
(320 plus pixels)
Recommended for unlimited data plans and WI-FI, such as the iPhone

Medium screen site
(240 plus pixels)
Recommended for all current devices

Small screen site
(120 plus pixels with low data weight)
Recommended for older devices and where data download is at a premium

Read more ...

Welcome to the New EXPTA {blog}

I hope you like the new template.  Please post a comment below if you have any problems viewing or using any of the new design elements.  I tested the new template using browsershots.org and it looks fine in most common browsers.

Read more ...