Welcome to MSDN Blogs Sign in | Join | Help

Where can I get Single Instance Store (SIS) for Windows File Servers?

The answer, it seems, is only from Windows Unified Data Storage Server 2003, which goes by so many other names, it can be challenging to understand sometimes.  However, the Single Instance Store, which is based on the Exchange and WDS technologies, detects multiple copies of the same document and consolidates them to a single document with mulitple pointers.  However, this feature is NOT available on any other edition of Windows Server.  Of course, this isn't well documented, as I tried to find out yesterday when doing a feature comparison. 

SIS is not part of Windows Server 2003 Standard, Enterprise or Datacenter (or Web), 32 or 64 bit.  SIS is not part of Windows Server 2008; ditto on the variations.  SIS is only available on WUDSS, which is, as of this writing, only available on the 2003 R2 platform. 

A version of Unified Data Storage Server (WUDSS) will be released in 2009 on the Windows Server 2008 platform and that specific SKU will have SIS incorporated into it.

Posted by anthonw | 3 Comments

When Legacies Are Baggage (Resolving the #550 5.1.1 RESOLVER.ADR.ExRecipNotFound error during Migration)

I was working with an education customer this week when I came upon an interesting problem related to mail routing for a specific user.  This user was migrated from one domain to another and mailbox-enabled for the new Exchange 2007 environment after their historical information had come over.  The user had three different SMTP email addresses, but the primary SMTP address, username@guessme.edu, kept returning mail as undeliverable.  The error information looks as follows.

 

Delivery has failed to these recipients or distribution lists:

 

[Removed]

 

The recipient's e-mail address was not found in the recipient's e-mail system. Microsoft Exchange will not try to redeliver this message for you. Please check the e-mail address and try resending this message, or provide the following diagnostic text to your system administrator.

 

Diagnostic information for administrators:

Generating server: HUBTransport.guessme.edu

IMCEAEX-_O=EWMAIL_OU=EXCHANGE+20ADMINISTRATIVE+20GROUP+20+28FYDIBOHF23SPDLT+29_CN=RECIPIENTS_CN=username@guessme.edu

#550 5.1.1 RESOLVER.ADR.ExRecipNotFound; not found ##

 

A quick look at the recipient (using get-mailbox | FL) shows the following (I have edited down the results to the most relevant information):

 

Database                             : IT-MAILBOX01\SG01\Database01

DeliverToMailboxAndForward           : False

RetentionHoldEnabled                 : False

EndDateForRetentionHold              :

StartDateForRetentionHold            :

ForwardingAddress                    :

ProhibitSendQuota                    : unlimited

ProhibitSendReceiveQuota             : unlimited

RecipientLimits                      : unlimited

SamAccountName                       : username

Alias                                : username

DisplayName                          : Last, First

EmailAddresses                       : {smtp:First.Last@guessme.edu, smtp:username

                                       @domain.guessme.edu, SMTP:username@guessme.edu}

HiddenFromAddressListsEnabled        : False

LegacyExchangeDN                     : /o=guessMeMail/ou=Exchange Administrativ

                                       e Group (FYDIBOHF23SPDLT)/cn=Recipients/

                                       cn=userName1

MaxSendSize                          : unlimited

MaxReceiveSize                       : unlimited

EmailAddressPolicyEnabled            : True

PrimarySmtpAddress                   : username@guessme.edu

RecipientType                        : UserMailbox

RequireSenderAuthenticationEnabled   : False

 

Again, mail flowed just fine to the non-primary SMTP addresses.  What was particularly interesting is that when Outlook was used, the user name was fully resolved against the address book and mail bounced.  When Outlook Web Access (OWA) was used, the mail didn't bounce, even though name resolution was occurring. 

 

Take a look at the relevant attributes from the Get-Mailbox cmdlet.  The problem in our case happened to be the LegacyExchangeDN.  Unknown to me (and the Exchange admin I was working with), the user account was migrated from the old domain, the alias changed (by removing the trailing number 1), and the mailbox was requested.  However, the LegacyExchangeDN gets created at the time of migration.  What should've happened is that the AD migration team should have altered the alias first, then migrated. 

 

The fix is pretty straight forward.  Remove the 1 from the LegacyExchangeDN attribute in AD Users and Computers.  Once we did this, mail began to flow again.

 

UPDATE: My customer pointed me to another blog that offers a great scripted solution for this.  http://mostlyexchange.blogspot.com/2007/08/exchange-2007-legacyexchangedn-and-mail.html

Posted by anthonw | 1 Comments

Windows Server 2008, IIS 7.0, Exchange 2007 and the Offline Address Book

I've been working through an interesting situation with one of my customers during the past couple of weeks.  For some reason, everytime Outlook 2007 clients attempted to download the offline address book (OAB), they would error out.  We found a lead at http://lugies15.blogspot.com/2008/09/offline-address-book-connecting-to.html and noticed that the permission change recommended here fixed the problem.  But we couldn't figure out why setting an open read permission to everyone on the c:\program files\microsoft\exchange\client access\oab folder would fix an issue of OAB failing to download.  They already had permission on the child folder and xml files through authenticated users.

Some basic troubleshooting steps involve testing the Outlook autoconfiguration to extract the URL that Outlook is using to pull the OAB from.  The URL for OAB was found to be https://server.domain.org/oab/guid-like-number/oab.xml.  When I tried to open it with Internet Explorer, I noticed that I was getting an access denied error, but not on the OAB.XML file, but rather the web.config file in the parent (/oab) virtual directory.

We traced this back to a configuration change we made a week earlier.  We wanted a redirect off the root folder to the /owa folder.  This was configured in the IIS 7.0 GUI, which results in the following configuration file.

<?xml version="1.0" encoding="UTF-8"?>

<configuration>

    <system.webServer>

        <httpRedirect enabled="true" destination="https://server.domain.org/owa" exactDestination="true" childOnly="true" httpResponseStatus="Permanent" />

    </system.webServer>

</configuration>

However, IIS 7.0 did not seem to respect "redirect this folder only" setting.  In fact, nearly all the subfolders, including /OWA and /OAB were redirecting, which effectively wiped out the OWA functionality.  This was fixed by disabling redirects in each of the affected child folders (note that some folders might be redirected by design and shouldn't be reversed - depending on your configuration and requirements).  That placed a web.config file in each of the child folders which looked like this:

<?xml version="1.0" encoding="UTF-8"?>
<configuration>
    <system.webServer>
        <httpRedirect enabled="false" />
    </system.webServer>
</configuration>

This config file was the file that our Oulook/IE client failed to read.  When we set permissions on this file such that Authenticated Users had read permission, the problem was resolved.  This explained why the configuration adjustment recommended at Lugie's blog made sense. 

Posted by anthonw | 0 Comments

Putting the F in FERPA (Building Distribution Groups for Class Schedules in Exchange)

One goal at many universities has been to provide a collaboration solution for students, based on email.  To do this in Exchange, an administrator needs to create a distribution list to represent the class and populate it with the user accounts.  Each distribution list has a members property and each user has a memberOf property, both of which are multi-valued attributes.  This is where the problems begin.

 

The Family Educational Rights and Privacy Act (FERPA) allow directory information on students to be published with permission, some information, such as the students' class schedules, must remain protected.  Further, with the introduction of Exchange 2007, Microsoft removed the functionality to hide membership of a distribution list (DL) from the interface because it wasn't a true security solution.  It couldn't protect the memberOf attribute on the user object, which meant the security was really only one way. 

 

What we're left with is a non-solution for addressing this common business challenge at colleges and universities.  Well, not entirely.  There is a massively complex mechanism in Exchange 2007 that could potentially hide both the members property of the DL and the student's class schedule (which would normally be read from the memberOf attribute).  The mechanism is the Dynamic Distribution Group (DDG) using a custom oPath filter. 

 

By default, Exchange 2007 ships with a really crappy oPath editor/wizard thing that allows you to do almost nothing useful in the creation of DDGs.  They augment this with a very useful PowerShell functionality that, because of a bug, doesn't actually work either.  Of course, all of this requires a new language called oPath, which is really just a dumb man's LDAP and it doesn't seem to have any purpose other than to create an LDAP filter.  (So, basically, the Exchange team creates a new complex query syntax whose only purpose is to translate into another complex query language that most of our customers were already learning anyway, but I digress). 

 

So what is the solution?  The solution is comprised of three steps: (1) create a standard security group, (2) populate the security group with users, and (3) build a custom dynamic distribution group whose filter is based on a user's membership in the security group.  An example explains this better.

 

I have three students: StudentA, StudentB and StudentC.  All three students belong to a class called MATH171S2: Calculus I – Section 2.  A security group called "f757b582ed2d3c241a798ff98c19774e" is created and populated with all three members.  Then, using the PowerShell interface, a Dynamic Distribution Group is created.  The filter query for this group seeks membership in the "f757b582ed2d3c241a798ff98c19774e" security group.

 

new-DynamicDistributionGroup -Name ' MATH171S2: Calculus I – Section 2' -RecipientFilter {(MemberOfGroup -eq 'CN= f757b582ed2d3c241a798ff98c19774e,CN=Users,DC=contoso, DC=edu' )} -OrganizationalUnit 'contoso.edu/Users' -Alias ' MATH171S2' -RecipientContainer 'contoso.edu'

 

Normally, this would be considered task-complete.  However, if you validate the membership list, you'll notice it's empty…

 

$T = Get-DynamicDistributionGroup -Identity ' MATH171S2'

Get-Recipient -RecipientPreviewFilter $T.RecipientFilter

 

But really it's not, because the following alteration to the PowerShell cmdlet does give us the DL membership.

 

Get-Recipient -RecipientPreviewFilter $T.LDAPRecipientFilter

 

What's going on?  Well, it turns out that the LDAP path we entered in the New-DynamicDistributionGroup cmdlet didn't translate properly.  Instead, it was saved as an oPath query into an AD attribute that expects an LDAP query.  If you look at the msExchQueryFilter attribute, you will see that 'CN= f757b582ed2d3c241a798ff98c19774e,CN=Users,DC=contoso, DC=edu' has been replaced with 'contoso.edu/users/f757b582ed2d3c241a798ff98c19774e' which is invalid, causing the failure.  Note that if you try to view the membership in the Exchange console, it will terminate and unload the module from MMC 3.0.  You must go in and change the msExchQueryFilter attribute back to its proper value. 

 

Another potential gotcha to watch out for is the scope of your filter.  Above, we set the –RecipientContainer attribute to the default domain container.  This tells Exchange that when searching for matches against the LDAP query, start in the default domain container and search it and all its child containers.  If your membership list seems only somewhat populated, you may have specified a bad RecipientContainer value.  This can be edited in the msExchDynamicDLBaseDN attribute of the DDG object in Active Directory. 

 

Is it worth it?  Clearly, this proposed solution puts the F in FERPA compliance.  It will require some sort of data store to manage the relationship between DDGs and SGs and creation of such groups (in large numbers) will require ADSI code to edit the various attributes back to their correct values.  However, this can be done fairly easily, but what do we really end up with.

 

1.       The user's membership in the security group is not visible in Outlook, but would be visible in raw LDAP queries against the directory. 

2.       Assuming the proper algorithm and salting, a user with access to the SG aliases will not be able to derive the DDG class names.

3.       A user with LDAP access to Active Directory will be able to view DDGs' attributes and derive which SGs they are associated with. 

4.       With explicit denies granted to domain users (people only) on the msExchDynamicDLFilter and msExchQueryFilter attributes, the association between the DDG and SG can be secured.  However, this must be done such that Exchange and AD administrators will have access to these attributes for management purposes.

 

All in all, it's a complex solution for what should be a trivial task, but I am open to your criticisms, suggestions and comments.

Posted by anthonw | 3 Comments

NoMAS and Other Solutions to 9548 and 9551 Events (Exchange Server 2003)

I thought I had posted this information several years ago, but a customer recently contacted me seeking it and I realized it never left the publishing stage.  Please note that this post is more specific to 5.5 to 2003 migrations, but may still be relevant to many folks out there.

 

After installing Exchange 2003 in your environment, you may see the following types of events in the event log of your Exchange Server 2003 machine.

 

Event Type:             Warning

Event Source:          MSExchangeIS

Event Category:       General

Event ID:                9548

Date:                      6/14/2005

Time:                     8:57:29 AM

User:                      N/A

Computer:               [2003 server name]

Description:

Disabled user /O=[LEGACY DN PATH]/CN=dZazzo (this could be any valid path to a user account) does not have a master account SID. Please use Active Directory MMC to set an active account as this user's master account.

 

Event Type:            Warning

Event Source:          MSExchangeIS Public Store

Event Category:       General

Event ID:                9551

Date:                      4/19/2005

Time:                     11:00:17 AM

User:                      N/A

Computer:               [Exchange 2003 Server]

Description:

An error occurred while upgrading the ACL on folder [Public Folders]/[Complete Path] located on database "First Storage Group\Public Folder Store (Server Name)".

 

The Information Store was unable to convert the security for /O=[LEGACYDN]/cn=DZazzo into a Windows 2000 Security Identifier.

 

It is possible that this is caused by latency in the Active Directory Service, if so, wait until the user record is replicated to the Active Directory and attempt to access the folder (it will be upgraded in place). If the specified object does NOT get replicated to the Active Directory, use the Microsoft Exchange System Manager or the Exchange Client to update the ACL on the folder manually.

 

The access rights in the ACE for this DN were 0x4fb.

 

It is important to have a full understanding of the reasons why these errors might be generated and know that the agency responsible for these errors may be remote to yours.  The following resources can be helpful in diagnosing the problem (excerpts below):

 

XADM: Addressing Problems That Are Created When You Enable ADC-Generated Accounts: This article provides information about disabled accounts that the Active Directory Connector (ADC) creates and describes how to enable those disabled accounts. The information store expects that disabled accounts will have a msExchMasterAccountSID attribute and that enabled user accounts will not have a msExchMasterAccountSID attribute.

 

How to troubleshoot public folder performance issues that are related to ACL conversions in Exchange 2000 and in Exchange 2003: This article describes how Access Control List (ACL) entries can affect Public Folder performance on a computer that is running Exchange 200x.

 

You cannot move or log on to an Exchange resource mailbox: This article has a general explanation of 9548 Event IDs and introduces the msExchMasterAccountSID attribute and how to eliminate 9548 events manually.

Additional Information about the MasterAccountSID

MsExchMasterAccountSid is generally used on disabled Windows 2000/2003 user accounts with Exchange mailboxes to store the SID of an NT4 account in a trusted domain.  This allows the NT4 account to access the Exchange 2000/2003 mailbox.  The Exchange Information Store logic looks at this attribute when a disabled user account is encountered, and uses this SID as the active SID, instead of the objectSid of the user, which is used if the account is enabled.  The active SID (either objectSID or msExchMasterAccountSID) is used to apply permissions within the information store, for example delegate permissions or public folder permissions.

 

User Type

ObjectSID

msExchMasterAccountSID

Active SID

Enabled User

Contains Value

Empty

ObjectSID

Disabled User

Contains Value (not used by default)

Contains Value

MasterAccountSID

 

If the user account is disabled, and no msExchMasterAccountSid is set, the store cannot determine which SID to add to the ACL.  In this case, the user is not added to the ACL, and 9548 event gets logged.  This can also cause a 9551 event to be logged, if the store is in the process of upgrading a DN-style ACL to a NT-style ACL.

 

Over the long-term, the accumulation of 9548 events can warn administrators of potential performance problems on the Exchange store, related to the enumeration of ghosted objects (disabled users).  If an ACE is a disabled account's objectsid, store expects the disabled account's mexchuseraccountcontrol to be 2, and msexchmasteraccountsid to be populated with another SID. If MAS isn't populated, the store won't know who the primary associated user is in order to grant/deny access to this folder later; hence the 9548 gets logged. 

 

The performance degradation will occur, regardless of whether the account accessing the folder is in a valid state or not.  So long as the folder has any Access Control Entries (ACEs) that are in  bad states (disabled without MAS, or DN-to-SID convert failed, which is the 9552 errors associated with converting Distribution Groups to Security groups), the store takes a performance hit. In the case of zombie permissions, users can also be denied access to the folder resource, even if they are ACL'd correctly. For that reason, I always recommend using the DS/IS consistency adjuster to remove unknown permissions from any folders before introducing E2k/E2k3 into a 5.5 site.

 

The “Associated External Account” (which can be found on the Mailbox Rights button from the Exchange Advanced tab of user properties in ADU&C) and msExchMasterAccountSid should always be in sync.  These requirements are not enforced by either AD or Exchange, but if they are not followed, either 9548 events will be logged, or access to resources may be unexpectedly denied, or both.

  

It is also possible (and the default behavior by the ADC when creating mail-enabled disabled user accounts) that the built-in security principle SELF can be set as the msExchMasterAccountSID.  This is perfectly valid, and tells the store to use the objectSid of the disabled account as the active SID when performing security operations.  This can also be used for scenarios where regular user accounts will be disabled for a period of time, and will possibly be enabled for use later, or deleted.

 

Resolution

At MCS, we recommend that if you disable your users as part of the standard employee exit process, you should grant the SELF built-in account full mailbox access and associated external account to the mailbox.  This will prevent problems with permissions and the proliferation of 9548 and 9551 event IDs in the application logs.

 

If a customer requires changes to hundreds of objects, they can also use the NoMAS.exe tool from Microsoft, which provides for bulk manipulation of these objects.  The NoMAS tool has the following requirements:

 

  1. NoMAS must be run in a domain with an Exchange 2003 representation.
  2. NoMAS cannot traverse domain boundaries
  3. NoMAS requires that the administrator running the utility be a member of the domain Admins group of the local domain.
  4. NoMAS requires Exchange Administrator permissions or greater on the mailbox stores of those objects being changed (this is typically accomplished with an account that has Exchange Administrator delegations at the Administrative Group level.

 

NoMAS is not supported by Microsoft.  Although PSS may assist with troubleshooting NoMAS issues, hotfixes and escalations for the tool will not be provided.

Posted by anthonw | 0 Comments

Installing Exchange 2007 SP1 onto Windows Server 2008 with a WS2008 Active Directory

This post consists of some notes that I took during the installation of Exchange Server 2007 SP1 (Integrated) into a Windows Server 2008 Active Directory Environment (green field, clean installation of everything).  The AD environment was created on RC1 bits of Longhorn with 2008 Forest Functional Level during the DCPromo process.  The lab consists of two servers: 1 DC and 1 Exchange Server. 

Install PowerShell Feature on both DC and Exchange Servers using the Server Manager - "Add Features" tool. 

ForestPrep and DomainPrep are no longer command line options in the Exchange setup process.  To build out the domain, run the following procedures on the domain controller:

SETUP /PrepareLegacyExchangePermissions:WS08.domain.com
SETUP /PrepareSchema
SETUP /PrepareAD /OrganizationName:WS08Mail
SETUP /PrepareDomain:WS08.domain.com

On the Exchange Server, add the web server role for IIS and ensure the following features are enabled:

  1. IIS 6 Management Compatibility
  2. Dynamic Content Compression
  3. Basic Authentication, Windows Authentication, and Digest Authentication 
  4. ASP.NET

Note that NNTP and SMTP are not required (and must not be installed).  Run a customized Exchange setup, configured for Mailbox, Hub Transport, and CAS roles.  Exchange performs a series of readiness checks and should provide ample instructions for installing or configuring any missing compoenents. 

Configure the Client Access Service

Set-OWAVirtualDirectory -Identity "[ServerName]\owa (Default Web Site)" -ChangePasswordEnabled:$false -ExternalUrl "{URL}"  -DefaultDomain [FQDN] -LogonFormat UserName -FormsAuthentication:$true

iisreset /noforce

Set-ExchangeServer -Identity [ServerName] -ProductKey "[Enter Product Key" -ErrorReportingEnabled:$true

Enable-OutlookAnywhere -Server [HostName] -ExternalAuthenticationMethod Basic -ExternalHostname [FQDN] -SSLOffloading:$false

Get-OabVirtualDirectory | where { $_.Server -eq [ServerName] } | Set-OabVirtualDirectory -ExternalUrl http://[FQDN]/OAB -RequireSSL:$true

Get-WebServicesVirtualDirectory | where { $_.Server -eq [ServerName] | Set-WebServicesVirtualDirectory -ExternalUrl https://[FQDN]/EWS/Exchange.asmx -BasicAuthentication:$true

New-ExchangeCertificate -GenerateRequest:$true -DomainName "[FQDN of Host]", "autodiscover.[FQDN]", "[FQDN]" -FriendlyName "[ServerName] cas cert request" -SubjectName "LegacyName" -Path "C`:`\[ServerName].req" -Keysize 1024

Configure the Hub Transport

Set-ExchangeServer -Identity [ServerName] -ProductKey "[Enter Product Key" -ErrorReportingEnabled:$true

Get-ReceiveConnector -Server [ServerName] | Set-ReceiveConnector -PermissionGroups AnonymousUsers,ExchangeUsers,ExchangeServers

$transportServers = Get-ExchangeServer | where { $_.IsHubTransportServer -eq $true }
Set-SendConnector "General Send Connector" -SourceTransportServers $transportServers

New-ExchangeCertificate -GenerateRequest:$true -DomainName "[FQDN of Host]", "autodiscover.[FQDN]", "[FQDN]" -FriendlyName "[ServerName] cas cert request" -SubjectName "LegacyName" -Path "C`:`\[ServerName].req" -Keysize 1024

 

Posted by anthonw | 0 Comments

The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll

Every now and then, I take a break from federated infrastructure to post something that is likely only relevant to me.  I recently purchased a new sound card (Creative Soundblaster X-Fi Extreme Audio) for a machine that is still running Windows XP.  I allowed the hardware wizard to recognize the device and pull the drivers from the CD that came with the card.  Some way into the installation, I blue-screened.  From that point forward, I could not keep the system up, so I rebooted to safe mode, pull the driver, rebooted normally, canceled the wizard installation and ran the direct install off the CD.

After that, everything worked fine, save one little issue.  At every logon, I received two errors.  The first error was:
RUNDll32.exe Entry point not found
The procedure entry point_except_handler4_common could not be located in the dynamic link library msvcrt.dll

Followed by:
Error loading P17RunE.dll
The specified procedure could not be found.

I also got an immediate notification from Creative that my drivers required an update.  I allowed the update, but found it interesting that the background screen indicated it was a Vista driver update.  Unfortunately, it couldn't be canceled.  Upon finishing, I received no errors, no BSODs, but couldn't get past the DLL errors.  I tried re-installing the msvcrt.dll from the original media, no changes.  It wasn't until I came across some discussions on the Creative forums that I got my solution. 

To rid these annoying errors, and allegedly resolve the problem, I needed to remove all references in the RUN key (regedit) to P17RunE.dll.  I haven't had the time or desire to research it, but I suspect that P17RunE.dll has some specific calls in Vista that don't exist in XP, hence the exception being thrown.  Removing the registry keys has proven stable.

Hat tip to jimholly who deserves the credit.

Posted by anthonw | 6 Comments

Pool Nonpaged memory Leaks on Exchange 2003

I am working with two independent customers.  Each of these customers is running Exchange 2003 on the backend, but have been working over the last several months to upgrade their clients to Office 2007, including Outlook 2007.  In most cases, desktops were remaining on Windows XP, although some Vista clients were thrown in the mix.  In both situations, as the number of Outlook 2007 clients increased against a 2003 backend, the customers have noticed Pool Nonpaged Memory problems.  We've considered and made adjustments for the information called out in http://support.microsoft.com/kb/912376.  However, the problem hasn't gone away.  Upon further investigation (which wasn't necessarily obvious at first), we discovered that Outlook 2007 was found to have opened several hundred (in some cases more than 700) TCP sessions to the Exchange Server. 

Upon restarting Outlook and allowing it to run, we could see a linear progression in the available memory on the server over the course of even one hour, up to the point where it would potentially cause a server crash.  In one customer's case, the server was actually crashing almost daily.  We disabled the TCP Chimney on the server as well as TCPA and RSS, just to rule out some of the potential issues with Windows 2003 SP2 and Exchange 2003.  No changes.  We investigated the possibility of add-ins in Outlook 2007 causing the problem.  Again, no luck. 

Finally, one of our support engineers uncovered the issue.  Normally, Microsoft Outlook retains a list of servers that it cannot connect to. When Outlook cannot connect to a server by using a Remote Procedure Call (RPC), it adds that server to the list. Even when Outlook is not running as a foreground program, it periodically tries to contact the servers in the "dead server list" to see if they are available again.

He found that in Outlook 2007 using Asynchronous RPC, there appears to be a connection leak when a server needs to be added to the Dead Servers List.  In one particular customer case, we found that the default public folder store for the majority of the customer's users was pointed to a Public Folder store that was not operational.  This caused Outlook 2007 clients on that store to build connections until the server eventually ran out of Nonpaged Pool Memory. Investigation continues as to whether this is isolated or more of a general problem.

UPDATE: I've received a number of questions about this post.  I've talked this over with the Premier Engineer and he provided this guidance to see whether this problem might what's causing you grief.  Look for the number of connections per client to Exchange.  Use netstat to grab the connections, pump to a text file, and group the connections in Excel.  If you see more than about 15-20 connections from a single IP to the Exchange server, this may be your problem.  Otherwise, you're not likely experiencing this issue.  Finding the cause of the problem, however, could still be challenging and possibly unique to each customer.

Posted by anthonw | 1 Comments

Using Powershell to Correct 9325 Events in Exchange 2007

Per knowledge base article 936197, Exchange 2007 may be dropping recipients from the Offline Address book and generating any of the following errors in the event log (note that diagnostic logging on the Exchange server needs to be set to High or Expert to see these events).

 

Event Type:       Error

Event Source:     MSExchangeSA

Event Category:   OAL Generator

Event ID:         9325

Date:             8/23/2007

Time:             9:25:43 AM

User:             N/A

Computer:         {Exchange Server where OAB is Generated}

Description:

OALGen will skip user entry '{mailBox Name}' in address list '\Global Address List' because the SMTP address '' is invalid.

- [Address Book Name]

 

The KB article goes into detail about how to fix these problems from a one-off perspective.  However, if you find yourself with hundreds of these events, you'll need a PowerShell script to more effectively solve the problem.  The script below will take the user's .Mail attribute (WindowsEmailAddress) and sets it as the PrimarySMTPAddress for the user.  To work properly, you first need to generate a list of offending users.  DUMPEL is probably the easiest way to get this information, pulling the 9325 events into a text file, loading the file into Excel and stripping everything but the user name.  The result of this effort produces a text file similar to the following:

 

Rachel Rogers

Dave Smith

John Doe

Alice Anderson

 

Once we have the list, we can feed into the following PowerShell script (yours could be parameterized, but for ease of illustration, mine is hardcoded). 

 

$users = get-content ListToCorrect.txt

foreach ( $user in $users ) {

$oUser = get-mailuser $user

$winMail = $oUser.WindowsEmailAddress

     Set-MailUser -identity "$oUser" -EmailAddressPolicyEnabled:$false -PrimarySMTPAddress $winMail -WindowsEmailAddress $winMail

}

 

A simple update to the Offline Address Book (Get-OfflineAddressBook | Update-OfflineAddressBook) should produce a clean event log.

 

Posted by anthonw | 0 Comments

Mailbox Cleanup After Cross Organizational Moves

I thought I would share some code I wrote for doing bulk mailbox cleanups on Exchange 2003 for cross-organizational mailbox moves.  This code is nearly identical to that in my previous post, but this one takes an input file to process several mailboxes at once.  The input file must be tab-separated and contain the distinguished name in the first column and the smtp email address in the second.  No headers are necessary on the input file.

'*******************************************************************************

'*** Declare Variables

'*******************************************************************************

Dim oFS                    '*** Object variable for file system object

DIM strUserDN        '*** This is the distinguished name of the user (string)

DIM objUser          '*** Object variable for containing the user

DIM strEmailAddr     '*** This becomes the external-to-exchange email address that mail is forwarded to

DIM sFile            '*** String variable that holds the file name to open from the parameters

DIM oArgs            '*** Array Variable to hold parameter objects

DIM iFile            '*** Object variable that links to the file object being opened

DIM Values           '*** Holds the CSV values in an Array

'*******************************************************************************

'*** Initialize and Declare Variables and Parameters

'*******************************************************************************

On Error Resume Next

 

'*** Grab the file name from the arguments command line

Set oArgs = wscript.arguments

sFile = oArgs(0)

 

'*** Open the file, check the file, make sure it is valid format

Set oFS = CreateObject("Scripting.FileSystemObject")

Set iFile = oFS.OpenTextFile(sFile, 1)

 

'*** Loop through the file, and reset all mailbox properties

 

Do Until iFile.AtEndofStream

Do                                '*** Inner Do Loop

       Err.Clear

       Values = Split(iFile.Readline, Chr(9))

 

       '*** Set variables

       strUserDN = Values(0)

       strEmailAddr = Values(1)

 

       '*** Connect to the user and disable mailbox

       wscript.echo "Connecting to user " & strUserDN 

       Set objUser = GetObject("LDAP://" & strUserDN)

 

       If Err<>0 Then

              wScript.Echo "[ERROR] - COULD NOT BIND TO OBJECT " & strUserDN & ".  sKIPPING USER"

              wScript.Echo ".... " & Err.Description

              Exit Do

       End If

 

       wscript.echo ".... Removing mailbox"

       objUser.DeleteMailBox

       objUser.SetInfo()

 

       If Err<> 0 Then

              wScript.echo "[ERROR] - COULD NOT DELETE EXISTING MAILBOX.  ABORTING CONVERSION"

              wScript.Echo ".... " & Err.Description

              wScript.echo ".... Original Mailbox should be intact for user."

              Exit Do

       End If

      

       wscript.echo ".... setting email address: " & strEmailAddr

       objUser.MailEnable strEmailAddr

       objUser.Put "internetEncoding",1310720

       objUser.SetInfo()

      

       If Err<> 0 Then

              wScript.Echo "[ERROR] - COULD NOT MAIL-ENABLE USER."

              wScript.Echo ".... " & Err.description

              wScript.Echo "Mailbox has been disabled, but user is not in a mail-enabled state."

       End If

 

       Exit Do

Loop                              '*** Inner Do Loop

Loop

Posted by anthonw | 0 Comments
Filed under: ,

There is no primary SMTP address

Just a few more things I've noticed on the cross-organization mailbox move function in Exchange 2007.  On some recent occasions, we've been running the move-mailbox cmdlet with the -AllowMerge switch to copy a mailbox from the source forest/organization to the target.  After running the cmdlet, we receive the following warning:

 

Although the mailbox was moved to the target Microsoft Exchange server, an error occurred while the policies were being applied.  Proxy address policies, Unified Messaging settings, managed content settings, and Exchange ActiveSync settings may not be set correctly.  There is no primary SMTP address.

 

The "no primary SMTP address" seems to be the big clue as to what is going wrong here with our procedures.  After some digging, this is what we discovered and currently believe is the cause of the problem.  When the user is created in the target organization, we deliberately set the –EmailAddressPolicyEnabled:$false parameter on the set-mailbox cmdlet.  This is the same thing as un-checking the GUI checkbox "Automatically update email addresses based on email address policy." 

 

The target mailbox is given a primary SMTP address, but when we merge the two mailboxes, it appears that Exchange clears the primary address and then looks to the EAP to reset the primary address based on whatever policy the now migrated user falls under.  If the user doesn't have a policy, then Exchange simply does nothing, but is kind enough to warn us. 

 

I tested this theory with two accounts, one of which set EmailAddressPolicyEnabled to $true and one to $false.  The results were exactly as I expected.  The $true account moved across the organization without incident; the $false account experienced the same problem. 

 

So, what do you do if you need to have that check box cleared, but still need to merge mailboxes?  The current work-around is to run the set-mailbox cmdlet with the –PrimarySMTPAddress parameter specifying which of the addresses should remain primary.  It's important, however that you use the above parameter and not try to reset the mailbox using the –EmailAddresses parameter, as this will overwrite all existing addresses, including those legacy addresses that were just brought over from the source environment.

 

Posted by anthonw | 1 Comments
Filed under:

Having ZUNE Shuffle Issues?

Okay, so this has nothing to do with federated infrastructure, except that many of my customers have or are considering Zunes.  I have one and I have what I believe to be a common problem.  My music collection contains some content that may be inappropriate for children under the age of 30.  I also like to shuffle the music around.  It seems the easiest way to accomplish this is to create a playlist of all age-appropriate music and then shuffle that playlist.  So I create a playlist with probably 2,400 songs or so.  The playlist syncs to the Zune device, and then immediately disappears.  Never shows up again.

I split the playlist into two smaller ones, each of about 1,200 songs.  Now I can listen to half my collection, but every couple of days need to switch over to the other half.  So, I've been listening to my collection for about a month now and notice that is seems like a pretty tight rotation.  If I wanted that, I would just turn on the radio.  I also notice that several of the songs on my collection are not getting played at all.  So I begin doing some tests.

These are my results, but I would like to know if anyone else is seeing something similar.  The shuffle feature in the Zune does not appear to be random.  I've noticed it always plays the same subset of songs in the same order.  I verified this by writing down the first 10 songs in a "random shuffle."  I stopped the Zune, started it over, and got the same 10 songs again. 

My work-around has been to shuffle the playlist in the list editor and just play them sequentially.  The past couple of weeks have been great; I am hearing songs that I know have never played before on the Zune.  Anyone else notice this?

Posted by anthonw | 1 Comments

Moving Mailboxes Cross Organizations in Exchange 2007

I've seen a number of posts on other blogs talking about the new features of Exchange 2007 and the ability now to move mailboxes across organizations.  I currently have a customer engaged in a major consolidation of multiple Exchange 2003 organizations into a single forest, single Exchange 2007 organization.  The design for this customer calls for the following:

 

  1. Users will continue to log onto and operate from their current domains for their primary job functions. 
  2. Users will all have new accounts in the consolidated forest.  These accounts could be used as primary logons (where trust relationships exist), but that will be determined on a per-department basis.
  3. If possible, users should get a single sign-on experience when accessing their new mailbox.
  4. Outside of the requirement to flip the Outlook profile (for earlier versions of Outlook), users should experience minimal interruption.

 

Upon looking at the documentation for the move-mailbox cmdlet (note that cross-organization moves cannot be done in the GUI), it appears the the -AllowMerge parameter would best meet our needs.  The AllowMerge is documented by Microsoft at http://technet.microsoft.com/en-us/library/aa997599.aspx:

 

"The AllowMerge parameter specifies the merging of mailboxes if one mailbox already exists. You can use this parameter to move a mailbox between different organizations even if a target mailbox already exists. The contents of the mailbox are merged at the target. This parameter cannot be used if the NTAccountOU parameter is used."

 

The process calls for first moving the mailbox into the target domain, keeping the source domain mailbox open to users.  This can be done with the following cmd-let (simplified here):

 

$s=Get-Credential

$t=Get-Credential

 

Get-Mailbox -DomainController "[FQDN of Source DC]" -Credential $s -Identity "[email address]" | move-mailbox -TargetDatabase "Exch01\First Storage Group\Mailbox Database" -SourceForestGlobalCatalog "[FQDN of Source DC]" -GlobalCatalog "[FQDN of Target DC]" -DomainController "[FQDN of Target DC]" -SourceMailboxCleanupOptions none -SourceForestCredential $s -TargetForestCredential $t -Confirm:$false

 

This Powershell script will give us what we want, provided we have an existing user in the target forest with a matching SID.  Because we need the SID match for a mailbox move to work properly, we turn to ADMT v3.  For most organizations, this is already a no-brainer.  My particular customer, however, had already created a separate identity solution in the target forest, so we had to use ADMT to ensure that the source SIDs got matched to target accounts that were not necessarily the same person (from AD's perspective).  In order for ADMT to work as desired, we did need basically a perfect match on the sAMAccountName attribute.  Once the SIDs were matched, we had no problems moving mailboxes between organizations.

 

The other thing missing from the documentation is that Get-Mailbox doesn't work across forest trusts with a single account.  That is why we need two different variables for the source and target credentials.  This does appear to be a bug with the Exchange 2007 release.  No news on whether it will be updated in SP1. 

 

After the mailboxes have all been moved, it was pretty straight forward to merge the mailboxes.  The mailbox merge takes all the changes since the first move, and incorporates them into the target mailbox.  One thing I noticed, however, is that items deleted from the source inbox were not replicated as deleted to the target mailbox (although the target mailbox contained the items both in the inbox and deleted items folders).  However, if large scale deployments want to "flip the switch" overnight, the allowMerge functionality seems to get the job done.  The code we used to accomplish this, looked similar to the following:

 

$s=Get-Credential

$t=Get-Credential

 

Get-Mailbox -DomainController "[FQDN of Source DC]" -Credential $s -Identity "[email address]" | move-mailbox -TargetDatabase "Exch01\First Storage Group\Mailbox Database" -SourceForestGlobalCatalog "[FQDN of Source DC]" -GlobalCatalog "[FQDN of Target DC]" -DomainController "[FQDN of Target DC]" -AllowMerge -SourceForestCredential $s -TargetForestCredential $t -Confirm:$false

 

The end result is that the move-mailbox function brought over all the user's content, updated the attributes in the target domain for each user so that reply-ability was preserved, and generally made for a pretty cool solution to a historically difficult problem.  The drawback, however, of the tool is that the objects in the source domain are not treated.  In other words, if only half the users are migrated to the new environment, mail-flow between the two organizations becomes broken in the source domain.  This is further complicated by the fact that Exchange 2003 doesn't respect the disable-mailbox and enable-mailuser cmdlets that could have been used to create proxies in the source domain.  Your mileage may vary on this specific problem, but in the case of our consolidation project, the source and target had different administrators. 

 

We simply ran out of options for PowerShell and had to turn back to ADSI+VBScript to get the job done.  The Script is pretty simple, and pretty straight-forward.  It can be run by either the administrators of the source domain or target domain, so long as it was run on an Exchange Server in the source domain.  In our actual production implementation, we used a single CSV file to pipe in the users for both the powershell and vbscript functions.  To preserve the anonymity of the customer, however, I am just sharing below the code we actually used to disable the source mailbox for a user, followed by re-mail-enabling the user as a "contact" (actually, a mail-enabled user pointing to the target forest).

 

Option Explicit

 

DIM strUserDN   '*** This is the distinguished name of the user (string)

DIM objUser  '*** Object variable for containing the user

DIM strEmailAddr '*** Populate with the external email address of the mail-enabled user

 

'*** Set variables

strUserDN = "[Distinguished Name of Account]"  

strEmailAddr = "[email address]"

 

'*** Get user object

wscript.echo "Connecting to user " & strUserDN

Set objUser = GetObject("LDAP://" & strUserDN)

 

'*** Wipe out the existing Mailbox

wscript.echo "Removing mailbox"

objUser.DeleteMailBox

objUser.SetInfo()

 

'*** Okay, now let's mail-enable it

wscript.echo "mail-enabling the user with address: " & strEmailAddr

objUser.MailEnable strEmailAddr

objUser.Put "internetEncoding",1310720

objUser.SetInfo()

 

Posted by anthonw | 2 Comments

Improving the Exchange Availability Report

So, maybe it's not a total improvement, but I thought it would be worth sharing.  The following SQL commands are designed to create a new, indexed table, and populate that database with Exchange Availability reporting data from the MOM System Center Reporting database in SQL Server (see previous post on the current availability report).

Unlike the SQL Reporting Services, this is a Query Analyzer solution.  You'll need to wrap the appropriate presentation layer around it.  The final step in the code is to write a stored procedure that accepts two parameters, start date and end date.  It returns total uptime for all Exchange servers in the environment, as well as some statistics for the report in general (as a separate recordset). 

As is typical, this code is for illustrative purposes only.  What you might find interesting, however, is the complexity of the data in the SystemCenterReporting database, and the requirements to massage that data into a usable format.  If you try this an run into any issues, let me know about them.

CREATE TABLE EXCHANGEAVAILABILITY
(
ComputerName VARCHAR(255) NOT NULL
, Message VARCHAR(1000) NOT NULL
, NTEventID INT NOT NULL
, ServerWhereLogged VARCHAR(255) NOT NULL
, Source VARCHAR(255) NOT NULL
, TimeGenerated DATETIME NOT NULL
, TimeStored DATETIME NOT NULL
, UserName VARCHAR(255) NOT NULL
, ComputerDomain VARCHAR(255) NOT NULL
, DomainWhereLogged VARCHAR(255) NOT NULL
)

GO

CREATE  INDEX [IX_TimeGenerated]
ON [dbo].[EXCHANGEAVAILABILITY]([TimeGenerated])
ON [PRIMARY]

GO

CREATE INDEX [IX_ComputerName]
ON [dbo].[EXCHANGEAVAILABILITY]([ComputerName])
ON [PRIMARY]

GO

CREATE INDEX [IX_EventID]
ON [dbo].[EXCHANGEAVAILABILITY]([NTEventID])
ON [PRIMARY]

GO

INSERT ExchangeAvailability
SELECT   [ComputerName]
 , [Message]
 , [NTEventID]
 , [ServerWhereLogged]
 , [Source]
 , [TimeGenerated]
 , [TimeStored]
 , [UserName]
 , [ComputerDomain]
 , [DomainWhereLogged]
FROM [SystemCenterReporting].[dbo].[SDKEventView]
WHERE NTEventID IN (9980,9981,9982,9983)

Go

if exists (select * from dbo.sysobjects where id = object_id(N'[dbo].[ExchangeUptime]') and OBJECTPROPERTY(id, N'IsProcedure') = 1)
drop procedure [dbo].[ExchangeUptime]

GO

CREATE PROCEDURE dbo.ExchangeUptime
 @StartDate DATETIME
 , @EndDate DATETIME
AS

DECLARE @ExpectedCounters INT
DECLARE @ActualCounters INT
DECLARE @SERVERCT INT

SELECT @SERVERCT = Count(Distinct ComputerName) FROM EXCHANGEAVAILABILITY
SET @ExpectedCounters = (CONVERT(INT,@EndDate) - CONVERT(INT,@StartDate)) * 288 * @ServerCt
SELECT @ActualCounters = COUNT(NTEventID) FROM EXCHANGEAVAILABILITY WHERE TimeGenerated BETWEEN @StartDate AND @EndDate

-- Build a temporary table to limit results
CREATE TABLE #DRange (
    ComputerName VARCHAR(50)
  , E9980 INT
  , E9981 INT
  , E9982 INT
  , E9983 INT
  )

CREATE TABLE #Report (
    ComputerName VARCHAR(50)
  , E9980 INT
  , E9981 INT
  , E9982 INT
  , E9983 INT
  )

INSERT #DRange
SELECT ComputerName
 , CASE NTEventID
  WHEN 9980 THEN -- SUCCESS
   COUNT(NTEventID) ELSE 0
  END AS TotalUptime
 , CASE NTEventID
  WHEN 9981 THEN -- DC Unavailable
   COUNT(NTEventID) ELSE 0
  END AS DCDown
 , CASE NTEventID
  WHEN 9982 THEN -- Exchange Down
   COUNT(NTEventID) ELSE 0
  END AS ExchangeDown
 , CASE NTEventID
  WHEN 9983 THEN -- Other Issues
   COUNT(NTEventID) ELSE 0
  END AS OtherDown
FROM  EXCHANGEAVAILABILITY
WHERE TimeGenerated BETWEEN @StartDate AND @EndDate
GROUP BY ComputerName, NTEventID
ORDER BY ComputerName

INSERT #Report
SELECT   ComputerName
 , SUM(E9980) AS E9980
 , SUM(E9981) AS E9981
 , SUM(E9982) AS E9982
 , SUM(E9983) AS E9983
FROM  #DRange
GROUP BY ComputerName

SELECT   ComputerName
 , CONVERT(DECIMAL(18,6),E9980)/(CONVERT(DECIMAL(18,6),@ActualCounters)/CONVERT(DECIMAL(18,6),@ServerCt)) AS SystemUptime
 , 1 - (CONVERT(DECIMAL(18,6),E9981)/(CONVERT(DECIMAL(18,6),@ActualCounters)/CONVERT(DECIMAL(18,6),@ServerCt))) AS DCUptime
 , 1 - (CONVERT(DECIMAL(18,6),E9982)/(CONVERT(DECIMAL(18,6),@ActualCounters)/CONVERT(DECIMAL(18,6),@ServerCt))) AS EXUptime
 , 1 - (CONVERT(DECIMAL(18,6),E9983)/(CONVERT(DECIMAL(18,6),@ActualCounters)/CONVERT(DECIMAL(18,6),@ServerCt))) AS DependsUptime
FROM #Report
UNION
SELECT
   'All Systems' AS ComputerName
 , AVG(CONVERT(DECIMAL(18,6),E9980)/(CONVERT(DECIMAL(18,6),@ActualCounters))) AS SystemUptime
 , AVG(1 - (CONVERT(DECIMAL(18,6),E9981)/(CONVERT(DECIMAL(18,6),@ActualCounters)))) AS DCUptime
 , AVG(1 - (CONVERT(DECIMAL(18,6),E9982)/(CONVERT(DECIMAL(18,6),@ActualCounters)))) AS EXUptime
 , AVG(1 - (CONVERT(DECIMAL(18,6),E9983)/(CONVERT(DECIMAL(18,6),@ActualCounters)))) AS DependsUptime
FROM #Report

SELECT    @ExpectedCounters AS EXPECTED
 , @ActualCounters AS ACTUAL
 , CONVERT(DECIMAL(18,6),@ActualCounters)/CONVERT(DECIMAL(18,6),@ExpectedCounters) AS Confidence
 , @ServerCt AS Servers
 , MIN(TimeGenerated) AS FirstEvent
 , MAX(TimeGenerated) AS LastEvent
FROM EXCHANGEAVAILABILITY
WHERE TimeGenerated BETWEEN @StartDate AND @EndDate

DROP TABLE #DRange
DROP TABLE #Report

GO

Posted by anthonw | 3 Comments

What exactly is "No Measurement %" in the MOM 2005 Exchange Availability Report?

If you've used the MOM 2005 Exchange availability report, you probably accepted the default parameters (which are exactly one week from the current time) and got a report that looked something like the following:

Server Database Availability % Success/ Expected Exchange Unavailable % DC unavailable for authentication % Other Failures % No Measurements %
DOMAIN\SERVER Mailbox Store 89.88 1812/2016 0.00 0.10 0.00 10.02

You're likely to be asking the question, "Why do I have no measurements nearly 10% of the time?"  Doesn't that make the report essentially worthless?  A better question to be asking is what exactly is Microsoft Operations Manager reporting here.  What exactly does "No Measurement %" mean?

The Exchange availability report is based on a MOM script that regularly pings the Exchange Server and Global Catalog Servers, looking for a response.  Every time the script fires (which is 12 times per hour), it will record the results in the MOM event log, with the following event IDs:

9980 Successful logon 
9981 DC unavailable 
9982 Exchange unavailable 
9983 Other failures

When the report is launched, it looks at the start time and end time parameters and calculates the expected number of events.  By default, the report runs for a one-week period, which is the equivalent of 2016 events.  If the MOM server has 2016 events during that date range, the No Measurement % value will equal zero.  If the event count is less than 2016, the No Measurement % column will be adjusted accordingly for the number of missing data points.

The reasons for missing data points fall into two categories:

  1. The data has not been populated into the reporting database.  This could be caused by either the refresh job failing, or specifying a date range that exceeds the boundaries of data in the database (either the data hasn’t been copied over yet, or it has been archived out of the database).
  2. The MOM agent script failed to fire.  This is unusual, but can be expected about 0.1 % of the time.  This doesn’t mean that Exchange or AD is unavailable, just that MOM failed to test it (for whatever reason).

Consider some of the following versions of the same report, with varying time parameters.  The following reports were run on September 26, 2006.

FROM TO SUCCESS/EXPECTED UNAVAILABLE NO MEASUREMENT
9/24/2006 4:00 PM 9/25/2006 4:00 PM 288/288 0% 0%
9/25/2006 4:00 PM 9/26/2006 4:00 PM 107/288 0% 62.85%
9/25/2006 4:00 PM 9/26/2006 1:00 AM 107/108 0% 0.93%
9/18/2006 4:00 PM 9/25/2006 4:00 PM 2008/2016 0.10% 0.30%
9/17/2006 4:00 PM 9/25/2006 4:00 PM 2295/2304 0.09% 0.30%
9/10/2006 4:00 PM 9/25/2006 4:00 PM 4301/4320 0.23% 0.21%
9/8/2006 4:00 PM 9/25/2006 4:00 PM 4877/4896 0.20% 0.18%
9/6/2006 4:00 PM 9/25/2006 4:00 PM 5186/5760 0.18% 5.04%
9/5/2006 4:00 PM 9/25/2006 4:00 PM 5186/5760 0.18% 9.79%

The results produced seem to confirm my initial assertions.  After the 18TH day, my "No Measurement %" began to increase rapidly.  It was also incredibly high (63%) for the previous 24 hours, yet 0% for the 24 hours preceding that.  I went back 19 days and started running the report for one day at at time.  What I found was that the report offered no data during any of those one day periods.  If it is not obvious to you yet, the MOM reporting database is being cleaned out, gradually, holding approximately 18 days of history (in my case, your mileage may vary).  In addition, it appears that the reason my numbers for "No Measurement" are so high on the default weekly report is that the report is that 15 hours have passed since the last time the database was refreshed, so I am missing approximately 180 counters (or 8.9% of the missing data). 

My conclusion, therefore is as follows.  If your No Measurement column is less than 1.0%, it is likely do to some type of systemic failure in the MOM agent that prevented it from running the script that collects the availability data.  If your number is greater than 1%, you should check your date parameters to see whether they are in line with what is actually contained in the reporting database.  Remember, the refresh runs (by default) at 1:00 AM each day, so you should never run the default date parameters for the report.  If you are specifying valid date ranges, and the No Measurement % value is extrordinary high, you might have a refresh problem with MOM and you should immediately check the SQL jobs to ensure they are running properly. 

Posted by anthonw | 0 Comments
Filed under:
More Posts Next page »
 
Page view tracker