Monday, October 29, 2007

Granting "Send As" rights in Exchange 2007

Many times it is necessary to grant a service account the ability to open a users mailbox and/or send email as that user.  Products that tightly integrate with Exchange like Blackberry Enterprise Server (BES), Quest Archive Manager (QAM), and many others need this in order to function properly.  This is accomplished by granting the service account the "Full Mailbox Access" and "Send As" rights for all mailboxes in the organization (assuming the application in question is to be rolled out enterprise-wide).

For those that are unclear, it is critical to understand the difference between "Send As" and "Send on Behalf Of".  "Send As" allows a user to "impersonate" another user and send email as the other user.  For example, if User A is granted "Send As" rights to User B's mailbox, then User A is able to send messages directly as User B and means that the recipient of the message will think that User B has sent the message, even though it was actually User A that sent it.  The "Send As" right can only be done by an administrator; a user cannot grant the "Send As" right to another user.

"Send on Behalf Of" allows a user to send email from another user's mailbox, but the sending user is not impersonated.  For Example, if User A is granted "Send on Behalf Of" rights to User B's mailbox, then User A is able to send message from User B's mailbox and the recipient would receive a message that is from "User A on behalf of User B".  By looking at the "From" field in the email, it is always very clear who is sending the message.  Like "Send As", the "Send on Behalf Of" right can be granted by an administrator, but unlike "Send As", "Send on Behalf Of" can also be established by the end user.  Through the Outlook client, a user can grant another user the ability to send on behalf of them.

For more information on granting "Send As" in an Exchange 2003 environment, or granting "Send on Behalf Of" permissions, check out this tutorial from MSExchange.org.

Now back to the problem at hand...

"Full Mailbox Access" and "Send As" rights can be granted on a single mailbox (or batch of mailboxes) with the following PowerShell cmdlets (using User A and User B from the examples above):

Add-MailboxPermission UserB -AccessRights FullAccess -user UserA

Add-ADPermission UserB -ExtendedRights Send-As -user UserA

Note that granting "Full Mailbox Access" does not include the "Send As" permission; "Send As" must be explicitly granted.

The problem with this method is that even if the script is such that it will grant the appropriate rights on all mailboxes in the environment, this will not automatically grant the rights to the service account for new mailboxes and the script must be re-run on a regular basis.  For message archival applications in particular this is a problem as some data may be missed because the service account was unable to access the mailbox.  So you must use a method to grant the required permissions automatically.

A personally recommended best practice is to create a group that has the "Send As" rights in Exchange and add the appropriate user accounts to that group.  Because there is risk with any account that has these rights to your entire Exchange organization, those account must be as secure as possible and the membership of that group must be controlled and monitored tightly.

To grant the required permissions, follow these steps:

  1. At the command prompt, type ADSIedit.msc. This requires the Windows Server 2003 Support Tools.
  2. In the Action menu, select Connect to…
  3. Select the Select a well known Naming Context radio button.
  4. Select Configuration from the drop-down list.
  5. The Default (Domain or server that you logged in to) radio
    button is selected. Leave this button selected if the machine you are
    logged in to is in the same domain as the Exchange 2007
    organization. If the machine you are logged in to is in a different
    domain, select Select or type a domain or server and enter the
    domain controller name.
  6. Click OK to return to the ADSI Edit window.
  7. Select the Configuration node that contains the name of the domain
    controller that holds your Exchange 2007 organization.
  8. Navigate to CN=Services | CN = Microsoft Exchange |
    CN=”Your Exchange Organization”
    .
  9. Right-click the organization node and select Properties.
  10. Select the Security tab and click Advanced.
  11. Click Add, and select the appropriate user or group.
  12. In the Permission Entry window, ensure that Apply Onto is set to This object and all child objects.
  13. Check the box for Full Control in the Allow column.
  14. Click OK to add the entry, and click OK to exit the windows.
  15. Close ADSIedit.

Be very sure that the accounts you use are not also in any groups which are denied "Send As" rights, or you will still be denied.  By default, the Domain Admins, Enterprise Admins, and Exchange Organization Administrators groups are denied "Send As" rights (and should be kept that way).

Awesome

A friend emailed me this today and although I had seen it a while back, it still cracked me up.  I'm not sure why it would be comforting to know that nothing I do will be as awesome as this, but it's still funny.

starwarsrocks

Friday, October 19, 2007

PdaNet vs. Internet Sharing on the AT&T Tilt

tilt1

One of the things I've been trying to get working with my Tilt is the ability to tether it to my laptop for data connectivity. AT&T offers a tethering option to data plans for $20, but I don't intend on using this 24/7 for an Internet connection, just something to use in a pinch. The AT&T cops swarming down on me is a chance I'm prepared to take.

The first thing I tried was PdaNet from June Fabrics. I used version 1.80 because it added WM6 support. I was wholly unsuccessful in getting this to work over USB or Bluetooth. I consistently got a "Modem is Busy" error, so I did a little more digging and found several others that had tried and failed to get PdaNet working with the Tilt. In the process, I also found out about Internet Sharing, a feature that (apparently) was offered on the 8525.

On the AT&T Tilt (the successor to the 8525), Internet Sharing was replaced by Wireless Modem in Connections. While Internet Sharing is no longer listed in Connections, it is still present on the device and can be used. Internet Sharing effectively does the same thing as PdaNet.

To locate Internet Sharing:

  1. Go to Start>Programs>Tools>File Explorer.
  2. Open the Windows Folder.
  3. Scroll down until you locate Internet Sharing.

To add a shortcut to an existing folder on your device:

  1. Tap and Hold on Internet Sharing and select Copy from the pop up menu.
  2. Navigate to a folder where you would like to put your shortcut and select Menu>Edit>Paste. I placed it in \Windows\Start Menu\Programs\Tools.

To use Internet Sharing:

  1. Pair your device with your PC (Bluetooth or USB).
  2. Locate the Internet Sharing shortcut you created and tap on it to open the application.
  3. Select USB or Bluetooth from the PC Connection type drop down (depending on your needs, obviously).
  4. Select MEdiaNet from the Network Connection drop down.
  5. Tap on Connect.

I tested this with Vista and didn't have any trouble with it.

UPDATE 03.12.08 - After a reader commented on not being able to get this to work with Vista, I realized I forgot one piece of the puzzle that I did well before I started to figure out Internet Sharing. In its default configuration, the Tilt wouldn't connect to Vista at all via USB (at least not with my laptop, so it's possible it is specific to my hardware). To fix this, go to Settings - Connections - USB to PC and turn off "Enable advanced network functionality" (whatever that is). You will need to re-enable this when you want to use it with XP.

Friday, October 05, 2007

Clustering in VMware Workstation 6

UPDATE 02.15.08: I updated the last line of the VMX file in step 4 (Thanks for the heads up Jim!)

I have a need to build an Exchange 2007 single copy cluster on Server 2003 in VM environment. This is something I've done before with Microsoft Virtual Server, but haven't had the opportunity to do it with VMware Workstation (OK, I had the opportunity, but never needed to until now). Since VMware Workstation is a paid product, I assumed clustering and setting up a shared SCSI bus would be included and pretty straightforward. Wrong. No options in GUI exist for this, and the VMware help files and knowledgebase provide no assistance. I love VMware, but come on, no easy way to set up a cluster in a product that is meant for lab testing various configurations and applications?


Anyway, after poking around on the web for a while, I was able to compile a working method for setting this up. Here are the steps I took:


  1. Create two VMs with a single disk on SCSI bus 0, install Windows, get updates, etc.

  2. On one VM, add two new SCSI disks (one for data, one for quorum) on SCSI bus 1 (I put them on SCSI1:1 and SCSI1:2), make them independent, persistent, and fully allocate the drive space so that the VMs don't fight over expanding/managing the disk file size.

  3. On the second VM, add the two already created SCSI disks on SCSI bus 1 (again, I put them on SCSI1:1 and SCSI1:2), and again make them independent and persistent.

  4. Edit the .vmx files for each VM and add the following lines:

    scsi1.sharedbus = "Virtual"
    disk.locking = "false"
    diskLib.dataCacheMaxSize = "0"
    diskLib.dataCacheMaxReadAheadSize = "0"
    diskLib.dataCacheMinReadAheadSize = "0"
    diskLib.dataCachePageSize = "4096"
    diskLib.maxUnsyncedWrites = "0"

  5. Fire up the VMs and both should have two disks ready for formatting and clustering.

Admittedly, the lines added to the .vmx file came from Geert Baeke’s Blog, specifically his posting on clustering in VMWare Workstation 4.5 and higher. Also, he has another good post around clustering in VMware Workstation using iSCSI. Trying that out is already on my “to do” list.

As a side note, when you complete botch the configuration of your Windows Cluster (like I did) and want to start over, use this command from the C:\windows\cluster directory on each node, then reboot the node:

cluster node <node_name> /forcecleanup