[HKEY_CURRENT_USER\Software\Policies\Microsoft\Office\15.0\common\contactcard]
"TurnOnLegacyGALDialog"=dword:00000001
"TurnOffHoverFunctionality"=dword:00000001

Local autodiscover for myserver.gov failed (0x8004010F)
Redirect check to http://myserver.gov/autodiscover/autodiscover.xml starting
Svr Record Lookup for http://myserver.gov/autodiscover/autodiscover.xml failed (0x80004005)

Initially, we focused on the 0x80004005 event and traced it to a problem with the IIS environment. A quick look at the IIS logs and client-side packet capture both showed a 301 (permanently removed) response from the web server. This didn't make much sense as Exchange is configured for a 302 redirect. After ruling out network connectivity issues, network load balancer issues and a few client side configurations, we found some data in the registry at the key HKEY_CURRENT_USER\Software\Microsoft\Office\12.0\Outlook\AutoDiscover (or 14.0 if you're using Outlook 2010). These values existed on the BPOS client machine but did not exist on mine.

"PreferLocalXML"=dword:1
"ExcludeHttpRedirect"=dword:0
"ExcludeHttpsAutodiscoverDomain"=dword:1
"ExcludeHttpsRootDomain"=dword:1
"ExcludeScpLookup"=dword:1
"ExcludeSrvLookup"=dword:1
"ExcludeSrvRecord"=dword:1

We set the values to zero and Outlook began behaving normally again. These values are installed and used in a variety of ways by customers of the Exchange Online service. The final resolution/cause appeared to be that the registry settings installed by BPOS prevented Outlook from using the HTTPS AutoDiscover service to get its configuration information.

See also http://social.technet.microsoft.com/forums/en-US/onlineservicesmigrationandcoexistence/thread/d6c69c69-6524-493b-a0c6-21c79e146ce7/

By default, Exchange 2010 ships with a Default [ServerName] receive connector on every machine with the hub transport role. One of the things that makes Exchange 2010 secure by default is that the default receive connector will not accept anonymous requests, will require at least one form of authentication, and will prefer TLS when possible. While this ensures internal message delivery across the SMTP protocol within your organization, it simultaneously prevents any messages from entering your environment from the Internet (arguably defeating the purpose of email). Email can enter your organization any number of ways, but one of the more common scenarios is through a hosted message security & hygiene service, like Microsoft's Forefront Online Protection for Exchange (FOPE). In this scenario, all email is referred to FOPE though the MX records. It is delivered to and scanned by the Microsoft service and relayed directly to your organization (either through an Edge role, or TMG/UAG-published hub transport role). Most customers (in its simplest, but rarest configuration) simply stand up a second receive connector designed to listen only to the FOPE address lists and allow anonymous authentication. That's what we had in this story, well mostly.

The customer had a TMG Firewall Sandwich that looked something like this:

SMTP-->FOPE-->Firewall Public-->NAT-->TMG Published SMTP-->Firewall (same one) Internal-->Load Balancer SMTP-->Hub Transport Role Server

What made it tricky was the security team's insistence that the internet-facing NIC on the TMG server be assigned a private address which was then published via Network Address Translation (NAT) behind the "real firewall." I won't even begin to discuss why this is a ridiculous design, but it was what we had to work with. So a SMTP Server publishing rule was created on the TMG server and directed to the Virtual IP (VIP) of the load balancer. The rule was designed to make SMTP traffic appear to come from the original sender (versus a proxy by the TMG server). Initial tests showed that the connection from FOPE was successfully reaching the TMG Server, and being passed through to one of the Hub Transport Servers. However, our TMG logs showed that no SYN/ACK was being received by the FOPE server and the connection was being closed. The log file on the TMG Server looked similar to the following:

 A connection was closed because no SYN/ACK reply was received from the server.

A little research confirmed my suspicions that blamed the firewall sandwich. Because outbound traffic inside the network was not configured to route back through the TMG, but instead directly through the "real firewall," all hopes of communication were lost on different highways. The quick and dirty fix, of course, is to change the configuration of the TMG rule to specify that Requests appear to come from the TMG Server. This solved the first problem, but mail still wasn't flowing. This made it necessary to crack open NetMon. Below is a synopsis of what we saw:

SMTP:Rsp 250 -(REMOVED)CAS01.customer.com Hello [IP REMOVED], 260 bytes
SMTP:Cmd STARTTLS, Server is currently able to negotiate the use of TLS
SMTP:Rsp 220  2.0.0 SMTP server ready, 29 bytes
SSL:SSLv2RecordLayer, Error (needs reassembly)
SSL:SSLv2RecordLayer, Client Finished (needs reassembly)
SSL:SSLv2RecordLayer, ClientHello (0x01) (needs reassembly)
SSL:SSLv2RecordLayer, Error (needs reassembly)

Basically, the connection was getting established, but any attempts to establish an SSL connection (TLS) were failing and the connection was being closed with a reset (RST) flag on the TMG logs. This is easily blamed on NAT. If TMG is going to negotiate security with FOPE, they need to be able to verify sending addresses, with which NAT interferes. And this is where receive connectors come into play. Our original internet receive connector was expecting everything to come from the TMG server, since it was terminating and replaying connections as part of its proxy duties. So, it was set up to allow port 25 from the IP Addresses assigned to the TMG server with anonymous access and default authentication mechanisms. Once the initial failures started, the thought was to disable TLS (all auth methods, actually) and that should solve our immediate problem. But it didn't.

I could see on the TMG that traffic was flowing to the VIP of the load balancer and SMTP traffic was answering from either of the two HT servers. So I installed NetMon on the HT server and watched both machines at the same time. What I discovered was that the TMG server was sending to the VIP of the load balancer, which was configured for SMTP load distribution. The load balancer was establishing a new session with the hub transport server. So the hub replied to the load balancer which replied to the TMG server. So my receive connector was never even getting used because it was expecting traffic from the TMG server that never arrived. What was happening is that all my traffic was going to the default receive connector that was still trying to use TLS and no anonymous. By now, I was wondering, how do I even know which receive connector I am talking to? There's an att(ribute) for that. Using the following cmdlet, you can establish a specialized banner message on your receive connector that will show up on the SMTP:220 response in either a telnet session or on the NetMon trace. The cmdlet is:

get-ReceiveConnector "[ServerName]\[ConnectorName]" | Set-ReceiveConnector -Banner "220 CAS01Default"

Your banner can say anything, but it should identify the server and connector in some way. Once establishing these for my primary receive connectors in question, I turned back on the NetMon trace and validated that, sure enough, all my traffic was by-passing the TMG receive connector in favor of the default, where it just failed. My solution was to adjust the address range of the TMG connector so that it contained the VIP of the hardware load balancer. Immediately, the SMTP traffic started flowing, end-to-end on all machines being monitored.

One word of caution. This is not an optimal solution, just because mail is again flowing. FOPE is TLS capable, as is this customer's environment. However, in the name of security, the security team "broke" the standard communication protocols at layers 3 and 4 of the OSI model. This ultimately prevented secure transmissions at layer 7 (TLS in Exchange). So, while mail is once again flowing, it is actually doing it in a less secure manner than if the firewall sandwich had just been abandoned as a security principle.

Most of the reseach indicated this was related to a network failure. We checked the hardware, software patches, drivers and everything seemed okay. Other events would also show up around the same time of day:

7024 Service Control Manager: The cluster service terminated with the service-specific error, "The membership engine requested shutdown of the cluster service on this node."

7031 Service Control Manager: "The cluster service terminated unexpectedly. It has done this 1 time(s). Correction action: restart service.

7036 Service Control Manager: The cluster service entered the running state.

Ultimately, this was traced to a backup utility running on the DAG member.

Instinctly, I blame the hardware.  We copy the CD contents (the CD is known good) to a local drive and try running setup from the E: drive.  Same thing.  At this point, I am at wits' end and the customer suggests taking the CD from the host server, putting it into the laptop's DVD drive (which is remotely connected to the remote desktop session).  I'm not crazy about the speed problems we're going to encounter, but I agree, because I need to rule out hardware.

As I started the post so too will I end it.  It's always the hardware.

The second issue extracting numerical information from the Get-MailboxStatistics cmdlet for attributes like TotalItemSize.  By default, it's reported as "250.1 MB (262,144,128 bytes)."  While that looks pretty and is even fairly easy to read, it doesn't aggregate well in an Excel pivot table.  It needed to be converted to a numeric value and functions exist to do so.  By calling out $object.TotalItemSize.Value.ToBytes() we can get a numer to display in the console, but I found it particularly challenging to assign the value to returned to a variable.  After several iterations, including some painfully challenging string breaking and re-concatenation, I came upon the idea to use Select-Object.  While it certainly seems like an unnecessary complication, I am pleased to see it works.  I am also happy to share it, because I know from my own research that many others are experiencing this same request. 

## Create a new variable, specified as an array
$MailboxData = @()

## Create a top-level loop for each customer's scope.  Even though we grab the OU below, we need a controlled input file for aligning
## discontiguous scopes with specific billing codes.  The CID code is considered the billing code for report purposes.
ForEach ($Customer IN Import-CSV [Insert Name of Input File]) {

 ## Scope the output using a known scoped parameter from the input file
 Set-ADServerSettings -RecipientViewRoot $Customer.ViewRoot

 ## Now, loop through all non-legacy mailbox types in the defined scope (2010 mailboxes only in this case)
 ForEach ($mailbox in Get-Mailbox -ResultSize Unlimited | where{$_.RecipientTypeDetails -notlike "Legacy*"}) {

  ## Create a new database object to populate with several columns, listed below
  $DBObject = new-object PSObject

  ## Columns are grouped by source.
  ## The first group is all from the Agency Variable created by the top-level loop
  $DBObject | add-member NoteProperty -Name CID -Value $Customer.CID
  $DBObject | add-member NoteProperty -Name CustomerName -Value $Customer.CustomerName

  ## This group is extracted from the Get-Mailbox object data
  $DBObject | add-member NoteProperty -Name Alias -Value $Mailbox.alias
  $DBObject | add-member NoteProperty -Name EmailAddress -Value $Mailbox.primarysmtpaddress
  $DBObject | add-member NoteProperty -Name OU -Value $Mailbox.organizationalunit
  $DBObject | add-member NoteProperty -Name DisplayName -Value $Mailbox.DisplayName
  $DBObject | add-member NoteProperty -Name Database -Value $Mailbox.Database
  $DBObject | add-member NoteProperty -Name EmailAddressPolicyEnabled -Value $Mailbox.EmailAddressPolicyEnabled
  $DBObject | add-member NoteProperty -Name SingleItemRecoveryEnabled -Value $Mailbox.SingleItemRecoveryEnabled
  $DBObject | add-member NoteProperty -Name LitigationHoldEnabled -Value $Mailbox.LitigationHoldEnabled
  $DBObject | add-member NoteProperty -Name RetentionComment -Value $Mailbox.RetentionComment
  $DBObject | add-member NoteProperty -Name StartDateForRetentionHold -Value $Mailbox.StartDateForRetentionHold
  $DBObject | add-member NoteProperty -Name EndDateForRetentionHold -Value $Mailbox.EndDateForRetentionHold
  $DBObject | add-member NoteProperty -Name LitigationHoldDate -Value $Mailbox.LitigationHoldDate
  $DBObject | add-member NoteProperty -Name LitigationHoldOwner -Value $Mailbox.LitigationHoldOwner
  $DBObject | add-member NoteProperty -Name IsMailboxEnabled -Value $Mailbox.IsMailboxEnabled
  $DBObject | add-member NoteProperty -Name ModerationEnabled -Value $Mailbox.ModerationEnabled
  $DBObject | add-member NoteProperty -Name ThrottlingPolicy -Value $Mailbox.ThrottlingPolicy
  $DBObject | add-member NoteProperty -Name UseDatabaseQuotaDefaults -Value $Mailbox.UseDatabaseQuotaDefaults
  $DBObject | add-member NoteProperty -Name ProhibitSendReceiveQuota -Value $Mailbox.ProhibitSendReceiveQuota

  ## Create an object variable to store the get-mailboxstatistics object with select attributes that we can customize (as expressions) to make them
  ## friendly to an Excel or other computational environment.  If you will be adding attributes to this section, you need to add them both to the Select-Object cmdlet and the Add-Member.
  $MbxS = Get-mailbox $mailbox.alias | Get-MailboxStatistics | Select-Object LastLoggedOnUserAccount,LastLogonTime,totalDeleteditemsize,itemcount,storagelimitstatus,@{Expression={$_.totalitemsize.value.ToBytes()};Label="TotalMBSize"},@{Expression={$_.totalDeleteditemsize.value.ToBytes()};Label="TotalDeletedItemSize"}

  $DBObject | add-member NoteProperty -Name StorageLimitStatus -Value $MBxS.StorageLimitStatus
  $DBObject | add-member NoteProperty -Name Items -Value $MBxS.ItemCount
  $DBObject | add-member NoteProperty -Name TotalItemSize -Value $MBxS.TotalMBSize
  $DBObject | add-member NoteProperty -Name DeletedItemSize -Value $MBxS.TotalDeletedItemSize
  $DBObject | add-member NoteProperty -Name LastLogonTime -Value $MBxS.LastLogonTime
  $DBObject | add-member NoteProperty -Name LastLoggonOnUser -Value $MBxS.LastLoggedOnUserAccount
 
  ## This group is from the Get-User object
  $U = Get-User $mailbox.alias
  $DBObject | add-member NoteProperty -Name Company -Value $U.Company
  $DBObject | add-member NoteProperty -Name FirstName -Value $U.FirstName
  $DBObject | add-member NoteProperty -Name LastName -Value $U.LastName
 
  ## Append the row to the top-level variable used to store the array
  $MailboxData += $DBObject 

 }

## Now, let's loop around and get the next agency in the CSV input file

}

## Export the array to CSV file using the user supplied value (or default if none supplied)
$MailboxData | Export-Csv $o -NoTypeInformation

MapiExceptionNoAccess: Unable to set properties on object. (hr=0x80070005, ec=-2147024891)

You may also see several lines of diagnostic context.  It is my opinion that this is caused by a failure of the RBAC delegation model to adequately apply the necessary permissions in Active Directory to make the delegation work.  As evidence, I submit the following cmdlets that seem to validate a certain suite of permissions are necessary and granted to the built-in group "Public Folder Management."  We can look at the permissions on the store:

Get-PublicFolderAdministrativePermission "\" | where {$_.user -like 'root\public folder management'} | select accessrights

AccessRights
------------
{ViewInformationStore}
{AdministerInformationStore}
{ModifyPublicFolderACL}
{MailEnablePublicFolder}
{ModifyPublicFolderQuotas}
{ModifyPublicFolderAdminACL}
{ModifyPublicFolderExpiry}
{ModifyPublicFolderReplicaList}
{ModifyPublicFolderDeletedItemRetention}

and the complementary permissions in Active Directory appear to correspond.

Get-ADPermission -Identity "CN=ORG,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=root,DC=gov" | ?{$_.user -like "root\public folder management"}

AccessRights      ExtendedRights
--------------    --------------
{GenericRead}
{ExtendedRight}   {ms-Exch-Store-Create-Named-Properties}
{ExtendedRight}   {ms-Exch-Store-Admin}
{ExtendedRight}   {ms-Exch-Store-Visible}
{ExtendedRight}   {ms-Exch-Create-Top-Level-Public-Folder}
{ExtendedRight}   {ms-Exch-Modify-Public-Folder-Deleted-Item-Retention}
{ExtendedRight}   {ms-Exch-Modify-Public-Folder-Replica-List}
{ExtendedRight}   {ms-Exch-Modify-Public-Folder-Expiry}
{ExtendedRight}   {ms-Exch-Modify-Public-Folder-Quotas}
{ExtendedRight}   {ms-Exch-Modify-PF-ACL}
{ExtendedRight}   {ms-Exch-Create-Public-Folder}
{ExtendedRight}   {ms-Exch-Mail-Enabled-Public-Folder}
{ExtendedRight}   {ms-Exch-Modify-PF-Admin-ACL}

To test my theory, I granted the same permissions (highlighted above in red) to my newly created delegate group using the following cmdlets.

Add-ADPermission "CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=root,DC=com" -user "root\Delegated Messaging Admins" -AccessRights GenericRead
 
Add-ADPermission "CN=OrgName,CN=Microsoft Exchange,CN=Services,CN=Configuration,DC=root,DC=com" -user "root\Delegated Messaging Admins" -ExtendedRights ms-Exch-Mail-Enabled-Public-Folder

Logging off and back on, the delegation took and appears to be consistently working.  I have been unable to get a confirmed answer on whether this practice is supported but given the ease with which it's implemented, and the consistency with which it works, I am okay with taking the risk that it may require additional modifications in future versions or service packs. 

This document is based on Exchange 2010 SP1.

With the move to Exchange 2010, all departments were being consolidated.  While this won't impact migrated users, it will create issues for newly created users, groups, etc.  The business requirements were laid out as follows:

1.      All users will be assigned a three letter department/agency code that will be written to the company attribute on the user object.

2.      All mail-enabled groups must be named according to the following naming convention:

a.      <Agency Code> + "DL" + [User determined name]  -or-

b.      <Group Scope> + "-" + <Group Type> + "-" + <Agency Code> + [User determined name]

3.      All mail enabled public folders must end with "(<AGY>)" where <AGY> is the three-letter agency code for each department.

4.      The primary email address for all users is firstname.lastname@agy.company.com and must be all lower case without apostrophes.  Secondary email address is username@agy.comany.com.

5.      Existing user mailboxes will keep their existing email addresses, as some users are grandfathered in, even though they don't explicitly match the state requirement.  The email address policy is only to be applied to new users.

The first step involves differentiating the 2003 users to be migrated from new users that will be created new in 2010.  New users will all be covered by the new policy.  Existing mailboxes might still benefit from the policy, but must be individually evaluated to prevent mistaken overwrites.  Prior to migration, the EmailAddressPolicyEnabled property is set to false on all existing mailboxes. 

The second step was writing an oPath query that met the business requirements above.  This was ultimately written as follows:

 (

  (

      RecipientType -EQ 'UserMailbox' -OR

      RecipientType -EQ 'MailUser' -OR

      RecipientType -EQ 'linkedMailbox' -OR

      RecipientType -EQ 'SharedMailbox' -OR

      RecipientType -EQ 'RoomMailbox' -OR

      RecipientType -EQ 'EquipmentMailbox'

  )

  -AND  

  (

      company -like 'AGY*'

  )

)

-OR

(

  (

      RecipientType -EQ 'MailUniversalDistributionGroup' -OR

      RecipientType -EQ 'MailNonUniversalGroup' -OR

      RecipientType -EQ 'MailUniversalSecurityGroup' -OR

      RecipientType -EQ 'DynamicDistributionGroup'

  )

  -AND

  (

      DisplayName -like 'AGY DL*' -OR

      DisplayName -like 'U-S-AGY*'

  )

)

-OR

(

  RecipientType -EQ 'PublicFolder'

  -AND

  DisplayName -like '*(AGY)'

)

The oPath query must be collapsed for PowerShell consumption.  However, I noticed a few problems during that process.  The PowerShell cmdlet didn't like references to linked, shared, room or equipment mailboxes.  So, those parts of the oPath query were removed from the recipient filter attribute of the New-EmailAddressPolicy cmdlet. 

The second challenge when creating the new policy cmdlets was forcing the capital letters that might exist in someone's first or last name attributes to lowercase as well as removing the apostrophe.  This can actually be done with some of the same type of regular expressions as defined at http://technet.microsoft.com/en-us/library/bb232171.aspx.  Granted, it's a little more complicated, but mostly just hard to read.

SMTP:%rAa%rBb%rCc%rDd%rEe%rFf%rGg%rHh%rIi%rJj%rKk%rLl%rMm%rNn%rOo%rPp%rQq%rRr%rSs%rTt%rUu%rVv%rWw%rXx%rYy%rZz%g.%rAa%rBb%rCc%rDd%rEe%rFf%rGg%rHh%rIi%rJj%rKk%rLl%rMm%rNn%rOo%rPp%rQq%rRr%rSs%rTt%rUu%rVv%rWw%rXx%rYy%rZz%r''%s@agy.company.com

Coupled with our now collapsed oPath query, we have the powershell cmdlet that builds our new policies.

New-EmailAddressPolicy -name "AGY Users" -EnabledEmailAddressTemplates "SMTP:%rAa%rBb%rCc%rDd%rEe%rFf%rGg%rHh%rIi%rJj%rKk%rLl%rMm%rNn%rOo%rPp%rQq%rRr%rSs%rTt%rUu%rVv%rWw%rXx%rYy%rZz%g.%rAa%rBb%rCc%rDd%rEe%rFf%rGg%rHh%rIi%rJj%rKk%rLl%rMm%rNn%rOo%rPp%rQq%rRr%rSs%rTt%rUu%rVv%rWw%rXx%rYy%rZz%r''%s@agy.company.com","smtp:%m@agy.company.com","X400:c=US;a= ;p=Company;o=Exchange;" -RecipientFilter {((RecipientType -EQ 'UserMailbox' -OR RecipientType -EQ 'MailUser') -AND (company -like 'AGY*')) -OR ((RecipientType -EQ 'MailUniversalDistributionGroup' -OR RecipientType -EQ 'MailNonUniversalGroup' -OR RecipientType -EQ 'MailUniversalSecurityGroup' -OR RecipientType -EQ 'DynamicDistributionGroup') -AND (DisplayName -like 'AGY DL*' -OR DisplayName -like 'U-S-AGY*')) -OR (RecipientType -EQ 'PublicFolder' -AND DisplayName -like '*(AGY)')}

Excel has been a favorite among accountants pretty much since it was released.  Very few Microsoft products are loved by their users the way Excel is loved by the accounting community.  Most of our institutions are held together by monster spreadsheets with ridiculously complex formulas that only one or two people can actually decipher.  And that's okay.  Excel is a good product, but I recently found myself wanting for more.

This post, quite different from most, is not targeted at the people who keep mail and directory systems operating every day.  This post is targeted at bartenders seeking help with reducing or expanding their recipes for barrel aging, rebottling, whatever the current trend happens to be. 

One of my hobbies is the study of cocktails: their history, chemistry, creation, distillation, etc.  Recently, I've been in the habit of pre-bottling some of my favorite cocktails, which involves mixing large batches.  Of course, most cocktail recipes call for an ounce here or a dash there, but present quite the challenge when combining 750ml bottles of this and that.  Reductions were even more challenging.  How do I reduce another bartender's recipe, measured in metric bottles of x and quarts of y, such that it fits into a single 375ml bottle for testing and tasting.  So, I turned to Excel to help me with the math. 

To facilitate all the conversions, I created a series of functions in Excel.  These functions are snippets of code that work just like Excel's built-in functions.  So, let's say you have a recipe that calls for a dash of bitters.  You want to make 50 of these cocktails ahead of time.  How much should you pour into the mixer?  The formula in Excel would be written as follows:

=ConvDash2Tsp(50)

And the cell will display 6.25.  And, just like standard Excel formulas, these functions can be compounded.  So, if you want to see dashes translated to milliliters, you change the cell to:

=ConvTsp2Ml(ConvDash2Tsp(50))

where the inner formula's result is passed to the outer formula.  The result of the second formula tells us that 50 dashes equals 30.81 milliliters. 

It's unfortunate that for all the formulas offered by Excel, basic conversion between US and metric units were never considered.  I've put together a list of a few of them, mostly pertaining to volume, but you can certainly use these as you see fit and create some of your own using the basic template. 

The following code can be pasted into a new Macro window in Excel to take advantage of some of these conversion formulas.

Function ConvOz2L(oz)
'Converts US fluid ounces to liters
ConvOz2L = oz / 33.8140226
End Function

Function ConvL2Oz(L)
'Converts Metric Liters to US Ounces
ConvL2Oz = L * 33.8140226
End Function

Function ConvOz2ml(oz)
'Converts US Ounces to Milliliters
ConvOz2ml = oz / 0.0338140226
End Function

Function ConvTsp2Oz(tsp)
'Converts teaspoons to ounces
ConvTsp2Oz = tsp / 6
End Function

Function ConvTblsp2Oz(tblsp)
'Converts tablespoons to ounces
ConvTblsp2Oz = tblsp / 2
End Function

Function ConvDash2Tsp(dash)
'Converts dashes into teaspoons assumes 8 dashes in a teaspoon
ConvDash2Tsp = dash / 8
End Function

Function ConvTsp2ml(tsp)
'Converts teaspoons to milliliters
ConvTsp2ml = tsp * 4.9289216
End Function

Function ConvMl2Tsp(ml)
'Converts milliliters to teaspoons
ConvMl2Tsp = ml / 4.9289216
End Function

Function ConvCups2ml(cups)
'Converts US cups to milliliters
ConvCups2ml = cups * 236.58824
End Function

Function ConvMl2cups(ml)
'Converts milliliters to US cups
ConvMl2cups = ml / 236.58824
End Function

Function ConvQuarts2L(quarts)
'Converts quarts to liters
ConvQuarts2L = quarts * 0.94635295
End Function

Function ConvL2Quarts(L)
'Converts liters to quarts
ConvL2Quarts = L / 0.94635295
End Function

Function ConvL2Gal(L)
'Converts liters to gallons
ConvL2Gal = L * 0.26417205
End Function

Function ConvGal2L(gal)
'Converts gallons to liters
ConvGal2L = gal / 0.26417205
End Function

Function ConvL2Cup(L)
'Converts liters to cups
ConvL2Cup = L * 4.2267528
End Function

Function ConvCup2L(cup)
ConvCup2L = cup / 4.2267528
End Function

1. Open LDP
2. Select Controls from the Options menu
3. Under Load Predefinied dropdown, select Return Deleted Objects.
4. Choose the Check Out buton to load Obj Identifier 1.2.840.113556.1.4.417
5. Choose Check In without modification
6. Click Ok
7. From the View menu, choose Tree
8. Enter cn=deleted objects,dc=domain,dc=com into the BaseDN combo box
9. Browse away at all objects that have been deleted.