Exchange CSI

Windows Mobile emulators in Hyper-V internal network Win2008 R2

2009-08-11T19:49:00Z

2 items that will help WM emulators on Hyper V clients in Win2k8 R2…

1. upgrade the HyperV integration services

2. enable MAC address spoofing on the VM in network adapter settings

Here’s the details:

I just upgraded my VMs from Win2k8 to Win2k8 R2 RTM. I have my lab environments running in private networks to not interfere with our primary network. I haven’t confirmed if this same symptom affects VMs on the External virtual network connection type. My emulators were working fine before the upgrade, but after I was unable to get DNS proxies to GCs in the internal network.

The first part I needed to do was in the upgrade documentation. You need to rerun the Integration Services Setup from the virtual machine connection. There are helpful event ids 27 and 6 on the Sys log of the parent partition that help clue in this resolution.

Log Name: System

Source: VMSMP

Date: 8/10/2009 8:40:29 PM

Event ID: 27

Task Category: None

Level: Warning

Keywords: Classic

User: N/A

Computer: mcCSIlab

Description:

Networking driver on '01XP' loaded but has a different version from the server. Server version 3.2 Client version 0.2 (Virtual machine ID 8AF758FA-CA92-4583-BAE0-45360776EEDA). The device will work, but this is an unsupported configuration. This means that technical support will not be provided until this problem is resolved. To fix this problem, upgrade the integration services. To upgrade, connect to the virtual machine and select Insert Integration Services Setup Disk from the Action menu.

The second portion to fix was a bit more difficult to find. I saw ARP requests in Netmon that were never answered. This clued me in that the problem was with MAC addresses.

I’ve confirmed the resolution was to enable this setting –

So, it appears native security for the Win2k8 R2 Hyper-V clients is heightened to prevent MAC spoofing by default – MAC spoofing is exactly what the WM emulator does with the VPC network drivers to use the Hosts network card [which in this case is a client partition in Hyper-V].

I hope this helps!

How to set the Default Calendar permissions for all users in Exchange 2000, 2003 and 2007

2009-07-29T20:01:00Z

Configuring appropriate default calendar permissions globally in an Exchange environment can be accomplished for Exchange 2000, 2003 or 2007 with a handy tool called PFDAVadmin found here:

http://www.microsoft.com/downloads/details.aspx?familyid=635BE792-D8AD-49E3-ADA4-E2422C0AB424&displaylang=en

The Exchange 2007 commandlet Set-MailboxCalendarSettings only works for resource mailboxes and won't accomplish what PFDAVadmin can for calendar client permissions. The only commandlet currently that mirrors this capability simply retrieves client permissions on public folders Get-PublicFolderClientPermission

With PFDAVadmin, you have two options:

1) script or 2) GUI

Here is the details for how to accomplish this with a script:

The command line for PFDAVadmin will look like this -

PFDAVadmin –import –s <mailbox server shortname> -f <filename.txt> -scope mailboxes [the username, password, GC are optional]

Depending on the Permissions Role you want to set, the <filename.txt> will contain entries like this:

SETACL Mailboxes\<username>\Freebusy Data \Everyone <Role Permission> NO

SETACL Mailboxes\<username>\Top of Information Store\Calendar \Everyone <Role Permission> NO

So, your script will need to create a .txt file enumerating all the <username> aliases existing for each mailbox server. Once the files are created, the command line above will need to be run for each mailbox server. Examples of <Role Permission> are: None, Reviewer, Author, etc.

The reason \Freebusy Data is included in the <filename.txt> is so you don't run into the symptoms described in this article here.

The detailed instructions for the GUI are below and have been seen here and here

===================

The latest version on pfdavadmin (version 2.8) has a new feature “Set Calendar Permissions” which can be used for granting Default calendar permissions for each mailbox. The procedure listed below works for both Exchange 2003 and Exchange 2000.

======================
Here are the steps required:

· Launch PFDavAdmin.exe

· At the main PFDavAdmin window, select File / Connect and in the Connect window, specify the name of the Exchange server and global catalog server to connect to [make sure that the Connection option is set to All Mailboxes before clicking OK]

All mailboxes will then be displayed in the left-hand pane of the main PFDavAdmin window when you expand the Mailboxes object.

· From the Tools menu option, select Set Calendar Permissions.

· You will then be presented with an advisory dialog box informing you that you will be presented with another dialog box in which you can configure the permissions you would like to set on the calendar folders. There are no options here; just click OK.

You are then presented with the blank Permissions window.

· To add new permissions, click the Add button.

You will now be presented with a window.

· The Choose user area gives you the chance to add a single user, but in our case we want to modify the Default [which maps to the Everyone group] access to all mailboxes.

· Click the Browse button and in the following window, choose the domain name in the drop-down box

· From the list of objects displayed, choose the Everyone object. Once selected, click OK.

· Back at the Choose user window, the selected user field should now be populated with the Everyone user previously selected. Click OK.

You will now be back at the Permissions window but this time the Everyone user will be shown in the list of objects. However, note that the Role field is currently set to None.

· To change the Permissions role, highlight the Everyone user and then, on the right-hand side of the Permissions window, change the drop-down permissions box so that the Permissions role can be selected.

· Once the Permissions role has been selected, click OK to set. You should be presented with a dialog box informing you that you will be presented with a new dialog box that you can use to remove entities from the calendar permissions. As with the previous advisory dialog box, just click OK.

· You’ll then be presented with another blank Permissions window as before. In this case, we don’t want to remove any entries so just click OK.

· PFDavAdmin will then process the mailboxes. Once it has finished, just close the window and you’re done.

=============================

cryptic error from Test-ActiveSyncConnectivity

2009-05-13T23:48:00Z

I came across some strange output when running the Exchange 2007 commandlet

Test-ActiveSyncConnectivity

so I thought I'd share with those of you who might be trying to figure out what it means...

Test-ActiveSyncConnectivity -ClientAccessServer 02e2k7cas -TrustAnySSLCertificate:$true -LightMode:$true

CasServer MailboxServer Scenario Result Latency(MS) Error

--------- ------------- -------- ------ ----------- -----

02e2k7cas mclab02E2k7MB FolderSync Failure [System.Net.WebException]:

The remote server returned an error: (403) Forbidden.

HTTP response headers: MS-Server-ActiveSync: 8.1

Content-Length: 0

Cache-Control: private

Date: Wed, 13 May 2009 20:35:31 GMT

Server: Microsoft-IIS/7.0

X-AspNet-Version: 2.0.50727

X-Powered-By: ASP.NET

In the IIS logs I saw this:

2009-05-13 20:35:31 02E2K7CAS 192.168.0.31 OPTIONS /Microsoft-Server-ActiveSync/default.eas &Log=V120_LdapC1_LdapL0_RpcC0_RpcL0_ 443 mcLab02.internal\CAS_16d82a7964354994 192.168.0.31 TestActiveSyncConnectivity - 02e2k7cas.mclab02.internal 200 0 0 15

2009-05-13 20:35:31 02E2K7CAS 192.168.0.31 POST /Microsoft-Server-ActiveSync/default.eas Cmd=FolderSync&User=CAS_16d82a7964354994&DeviceId=996795128&DeviceType=TestActiveSyncConnectivity&Log=V120_LdapC0_LdapL0_RpcC10_RpcL0_Ers1_Error:
LegacyDeviceOnStrictPolicy_ 443 mcLab02.internal\CAS_16d82a7964354994 192.168.0.31 TestActiveSyncConnectivity - 02e2k7cas.mclab02.internal 403 0 0 31

The LegacyDeviceOnStrictPolicy helped me remember I had disabled ActiveSync for nonprovisionable devices here:

So, the error, although cryptic at first, was really there to tell me the account I tested has a mailbox policy that doesn't allow nonprovisionable devices. If you use System Center Operations Manager, you may also run into this error.

Mismatched CAS versions causes proxy to fail with Event id 46

2009-04-20T22:02:00Z

Event ID 46 for OWA CAS proxy really attempts to discuss two separate topologies as shown below. When CAS1 is the Internet facing CAS, you can manually copy the resource folder from CAS2 to CAS1 to resolve this issue. After copying the resource folder, you will need to restart the MSExchangeServicesAppPool.

When CAS2 is the Internet facing CAS, your only recourse is to install the matching rollup on CAS2 or uninstall all higher versions of rollups on CAS1.

Here’s the original language of Event ID 46 for both scenarios.

Log Name: Application

Source: MSExchange OWA

Date: <timestamp> PM

Event ID: 46

Task Category: Proxy

Level: Error

Keywords: Classic

User: N/A

To ensure reliable interoperability, the proxying Client Access server needs to be running a newer version of Exchange than the Client Access server it is proxying to. If the proxying Client Access server is running a newer version of Exchange than the Client Access server it is proxying to, the proxying Client Access server needs to have an Outlook Web Access resource folder (for example, "<Exchange Server installation path>)\ClientAccess\owa\8.0.498.0" that contains all the same versioned resource files as the Client Access server it is proxying to. If you will be running Outlook Web Access proxying with mismatched server versions, you can manually copy this resource folder to the proxying Client Access server.

Connecting Entourage with Exchange 2007

2009-04-17T23:41:00Z

The typical installation of Exchange 2007 includes the CAS, MBX and HUB roles. Entourage requires little if any server configuration to connect in this topology.

However, once these roles are separated, there’s a few additional steps to take.

One thing to note – you do not need to install the latest WebDAV component from the IIS team in order to get Entourage to work with Exchange 2007 on Windows 2008 server. If you’ve already installed the component:

http://learn.iis.net/page.aspx/350/installing-and-configuring-webdav-on-iis-70/

here are the steps to uninstall it:

On the Exchange 2007 server it’s installed

1) Stop the W3svc service [this usually prevents the need to reboot] net stop w3svc

2) Uninstall the WebDAV component from Control Panel, Programs and Features

3) Start the W3svc service net start w3svc

4) run the following commands from the Exchange Management Shell

Remove-OwaVirtualDirectory "exchange (default web site)"

-Refresh IIS manager to ensure the exchange virtual directory has been removed

New-OwaVirtualDirectory "exchange" -OwaVersion Exchange2003or2000 -VirtualDirectoryType Mailboxes -WebSiteName "Default Web Site"

5) Ensure the proper permissions are configured on the Exchange virtual directory:

CAS role == Basic

MBX role == Windows Auth [as well as SSL settings with Require SSL unchecked]

6) Run iisreset /noforce

The steps above show the basic setup requirements for Entourage:

On the CAS, the Exchange virtual directory needs to have Basic, on the MBX, the Exchange virtual directory needs to have Windows Auth and SSL turned off.

A great troubleshooting step from here is to enable Forms Based Authentication on the CAS for the OWA virtual directory in Exchange Management Console. Once that is enabled, if you see redirection working properly for OWA through your browser, then most likely your server is configured correctly.

For example, for Entourage to work, you need to be able to access https://CAS/exchange from the Apple client you want to run Entourage from [which after getting redirected to the OWA FBA page you should be able to log in]. From the CAS, you should also be able to access http://MBX/exchange - If these two tests work, then you most likely need to visit

931350 You cannot connect to your mailbox on Exchange Server when you use Entourage for Mac

It’s better to work from https://CAS/exchange to http://MBX/exchange - if connecting to the CAS won’t work, then connecting the MBX over the Exchange virtual directory won’t work either.

-austinmc

Autodiscover and the Active Directory

2009-02-20T22:15:00Z

When browsing through your Active Directory, you'll see Autodiscover objects in several places. Here I'm going to help explain a little bit about the differences between these objects and some simple ways to troubleshoot them. Using tools like ADSIedit or LDP can have far-reaching consequences. Don't use those tools to modify or delete objects unless you fully understand those consequences.

There are 3 primary locations of Autodiscover labeled objects.

Here is the portion of Autodiscover in Active Directory called the AutodiscoverVirtualDirectory that is easily added and removed with the Exchange Command Shell functions:
Remove-AutodiscoverVirtualDirectory -Identity "<CASNETBIOS>\Autodiscover (Default Web Site)"
New-AutodiscoverVirtualDirectory -WebSiteName "Default Web Site"

Here is the portion of Autodiscover in Active Directory called the Service Connection Point [SCP] that is only created during installation of the CAS role. Deleting this directly will require you to most likely uninstall the CAS role, replicate changes through your AD, then reinstall the CAS role.

Here is the portion of Autodiscover in Active Directory that configures Outlook Providers in regards to Outlook Anywhere. The Get, Set, Remove and New-OutlookProvider commandlets are used to configure this.