But there are two pieces to the archiving puzzle: Putting things into it, and taking things out of it. The first part can be largely automated and done according to a set of rules that specify that emails get archived after a certain period of time. But as for the other end—searching the archives—that’s another story entirely.

The process of e-discovery for example, can be a nightmare, and lawyers have been known to cast a very wide net. The results can easily be tens of thousands of emails or more. Ultimately, this needs to be the domain of the legal department, who will be better equipped than IT staff to conduct a search designed to yield usable results.

But besides legal e-discovery, nearly every department will have a need for retrieval at some point. It is simply a waste of resources to require the IT department to conduct these retrievals. In the old days, it was necessary. Archives were kept on tape, on a shelf in a back room. The tape had to be physically retrieved and then loaded and read. But we’ve gone beyond that (hopefully) today.

Retrieval can take one of many different forms. Of course, when end users store their own emails locally in folders or PST files, they can do it themselves, but the process is decidedly clunky and inefficient and may be error-prone. The process instead needs to be rules-based, centralized, and automated. Exchange allows for easy integration with third-party services that allow for this.

In establishing a search and retrieval function, the IT department should implement a solution that gives end-users easy access, but access that is controlled with authentication and authorization to guarantee continued compliance with security requirements. Furthermore, the end-user interface should be web-based so that access can be gained from any browser, and lastly, the search function should be made efficient by allowing searches to be conducted not only from the subject header, but from the content as well. From a compliance perspective, most regulations will require an audit trail as well, and it will also be necessary to choose a solution that will log access.

You can receive the error code 0×80004005 if you use Distributed Authoring and Versioning (DAV) to query for message properties on the information store in Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003. A 0×80004005 (ecCallFailed) error is returned if the urn:schemas:mailheader:to property is requested. Additionally, an error is returned if there are messages in the result set that have recipients where the value of PR_EMAIL_ADDRESS is an empty string (”").

You may also receive the error when you use xp_sendmail extended stored procedure to send e-mail from SQL Mail with SQL Server 2000. The error message you receive will look like: xp_sendmail:failedwithmailerror 0×80004005.

Another circumstance when you receive error code 0×80004005 is when you query for a specific MAPI interface by using a pointer that you obtained from an Outlook object’s MAPIOBJECT property. The error message is short: 0×80004005 (E_FAIL).

When this happens it is because The MAPIOBJECT property is available only for compatibility with Microsoft Collaboration Data Objects (CDO) 1.21. It is a hidden property of Outlook Object Model objects, and is not meant to be used from the Outlook object. The MAPIOBJECT property is meant to be used from the corresponding CDO object. To use the MAPIOBJECT property, use CDO to obtain it from the corresponding CDO object.

Additionally, a SQL Server Database Maintenance Plan includes an option to send a maintenance report (that is, a file that contains results for the execution of the maintenance plan) by e-mail to a predefined operator on the server. E-mailing the maintenance report file to the operator may fail with the following error message, which can be found in the maintenance report for the Database Maintenance Plan:

Error 18025: [Microsoft][ODBC SQL Server Driver][SQL Server]xp_sendmail: failed with mail error 0×80004005. 

Note that this error does not affect the reporting of the job status. The job is still shown as successful.

The xp_sendmail extended stored procedure fails with the 0×80004005 error when attempting to send an open file as an e-mail attachment. Sqlmaint.exe executes the Maintenance Plan and writes output to the report file. The final step in the Maintenance Plan, which is to send an e-mail, is also recorded in the report. Because the report file is still open when xp_sendmail tries to send it as an attachment, the attempt fails.

You can resolve this problem by obtaining the latest service pack for SQL Server 2000.

Microsoft has confirmed that this is a problem in SQL Server 2000. This problem was first corrected in SQL Server 2000 Service Pack 1.

To work around this problem, you can include the script below as an additional job step in the last job created by a particular Maintenance Plan. This script below sends the last report file for a specific Maintenance Plan to a specified e-mail address.

To use this workaround, follow these steps:

1. Identify the last job for the Maintenance Plan.
2. Right-click the job, click Properties, click Steps, select the step, and then click Edit.
3. On the Edit Job Step dialog box, click the Advanced tab.
4. Set On Success Action to Go To Next Step.
5. Click OK on the Edit Job Step dialog box.
6. Click New to add a new step, and then give the step a name. Type should be Transact-SQL Script (TSQL) and Database should be master.
7. Paste the following script in the command window:
   declare @planname varchar(100)
   declare @dir varchar(200)
   declare @operator varchar(50)
   declare @cmd varchar (200)
   declare @mailfilename varchar(200)
   declare @filenamelen int

Values set here can actually be provided as parameters to a stored procedure.

If provided as parameters to a stored procedure, rem the following select statements.
@plananme is the plan whose maintenance report is sent.
@dir is the log directory for SQL Server. It is the directory to which the maintenance report files are written.
@operator is the email address of the person to whom the report file should be mailed.

select @planname = ‘Database Maintenance Plan 1′
select @dir =’c:\Program Files\Microsoft SQL Server\MSSQL$SQL2K1\LOG’
select @operator =’email@domain.com’

You can automatically set the above by reading various values from SQL Server.

SET NOCOUNT ON
IF RIGHT (@dir, 1) <> ‘\’
begin
select @dir =@dir +’\’
end
SELECT @dir = ‘dir /s /b ‘+’”‘+@dir + @planname+’*.txt’+'”‘ +’ >c:\dir.txt’

create table #TMP_MAINT_FILENAMES (NAME1 varchar(8000))
exec xp_cmdshell @dir
BULK INSERT #TMP_MAINT_FILENAMES
   FROM ‘c:\dir.txt’
   WITH
      (
         ROWTERMINATOR = ‘\n’
      )

select @mailfilename=MAX(name1) from #TMP_MAINT_FILENAMES
print ‘The following file is being sent as an attachment’
print @mailfilename

Set the various parameters for xp_sendmail.
declare @tmpmessage varchar(300)
declare @tmpsubject varchar(300)
select @tmpmessage = ‘This is the last maintenance report on the server for the maintenance plan ‘+@planname
select @tmpsubject = ‘SQL Server Maintenance Report for ‘+@planname

Now send the last file for the maintenance plan.
exec master..xp_sendmail @recipients= @operator, @subject =@tmpsubject, @message=@tmpmessage,
@attachments= @mailfilename

Perform cleanup.
drop table #TMP_MAINT_FILENAMES
exec master..xp_cmdshell “del c:\dir.txt”
SET NOCOUNT OFF

8. Make sure that the @planname, @dir, and @operator values are set in the script.
9. Save the job step.

These programming examples are provided for illustration only, without warranty either expressed or implied. This includes, but is not limited to, the implied warranties of merchantability or fitness for a particular purpose. Make sure that you are familiar with the programming language that is shown and with the tools that are used to create and to debug procedures.

Mailbox Item Recovery for Exchange Server 2007

The backup utility that is provided with Windows Server 2003 is capable of backing up and restoring entire mailbox databases for Exchange Server 2007.  However it is not natively capable of restoring an individual mailbox item (such as a single email) should the need arise.

Some third party Exchange backup products do provide this functionality however this comes at a cost.  Fortunately all they are doing is providing a simple interface for a built-in feature of Exchange Server 2007 to perform the restore.

For businesses on a budget or anyone who simply chooses to use the built-in backup utility for backing up their Exchange servers you can still recover individual items thanks to Recovery Storage Groups.

What is a Recovery Storage Group?

A Recovery Storage Group is an Exchange Server 2007 feature that allows the administrator to create an “invisible” storage group that can be used to restore a mailbox database and extract data from it without affecting the production database that is being accessed by end users.

The Recovery Storage Group is only used for restore and recovery operations.  It is never connected to by an end user using Outlook or other mail protocols, and the mailboxes contained within it are not associated with any Active Directory user accounts.

Restoring Mailbox Items using the Recovery Storage Group

In this example the user “John Smith” has deleted an email from the inbox that was received last week.  The Mailbox server is backed up every night and so the email administrator knows that the item is likely contained within one of the previous nights’ backups.To begin the recovery process launch Database Recovery Management from the Toolbox of the Exchange Management Console.

Fill out the activity name, server name, and domain controller name and click Next to continue.

From the list of tasks choose “Create a recovery storage group”.

Link the Recovery Storage Group to the same storage group as the mailbox you intend to recover data from, and click Next to continue.

Give the Recovery Storage Group a name (the default name is fine) and modify the other settings if you wish.  The Recovery Storage Group does not need to be located on the same drive as the storage group or mailbox database you are recovering, but once it is created it cannot be moved so make sure you choose a location with enough free disk space to hold a copy of the mailbox database.

When this has completed go back to the task center and click on “Set up ‘Database can be overwritten by restore’ flag”.  Choose the mailbox database for the Recovery Storage Group and complete the task.

Now that the Recovery Storage Group has been created a restore operation from the Windows Server 2003 backup utility will recover data to the Recovery Storage Group rather than to the production database.

Once the restore has been performed click on “Mount or dismount databases in the recovery storage group”.  Select the mailbox database and click on “Mount selected database”.

Return to the task center.  Now we can begin to extract mailbox data from the Recovery Storage Group.  Click on “Merge or copy mailbox contents”.  The mounted database within the Recovery Storage Group will be selected.  Click on “Gather merge information”.

Click on “Show Advanced Options” and set the start data and finish date to the date range that you wish to recover mailbox items from.

Click on “Perform pre-merge tasks”.  A list of available mailboxes will be displayed.  Make sure you have only selected the mailbox that you wish to recover items for, then click on “Perform merge actions”.

When the merge has completed the items will be visible in the end user’s mailbox without them needing to restart Outlook.

After the mailbox item recovery is complete we need to remove the Recovery Storage Group from the server.  In the task center click on “Mount or dismount databases in the recovery storage group” and dismount the recovery mailbox database.  Return to the task center once more, click on “Remove the recovery storage group” and follow the steps to complete the task.

The campaign, based on the web site www.fixoutlook.org, sent tens of thousand of tweets on the subject. After 24,000 tweets in the first day, volume is down to about a thousand a day now.

Microsoft has no plans to change its strategy, and has said that it will continue using Word for rendering HTML in Outlook 2010. Those who are protesting the move do have a point, in that some of the more complex HTML layouts don’t work well (such as tables or background images), although for most routine HTML emails, there’s very little difference.

There is also a security consideration at work here, and using Word to render HTML does deliver a security advantage that can’t be disputed. Web browsers execute all the HTML code, but Word is not able to run active content, which is a factor in favor of keeping the Word rendering engine with Outlook–giving Outlook users an extra edge in the fight against malware attacks. The added risk may in fact be small, but in ensuring email security, there’s really no one approach. A multi-layered approach to email security is the most advantageous, and this means using multiple precautions.

Standard HTML email is prevalent, and it’s favored by almost anybody sending any type of commercial email, but there’s an inherent risk in that it’s just easier to mask something malicious, send a piece of malware with the email, or include image-based web beacons.

Such is the case with Error code 0×80040113. Surprisingly it can occur not only when using Outlook Mobile Manager but also when issuing a command to MSGraph that uses OLE automation. Sometimes the error occurs when using Personal Folders and you get a “Sending and Receiving reported error…” message.

Here are some related 0×80040113 error messages and some ways you can handle this error.

In the past, if you were using Microsoft Outlook Mobile Manager you may have received an error message such as “MAPI Error Occurred. (Error code 0×80040113)”. This issue could occur if your network connectivity was disconnected. Having your network connection get disconnected would prevent communication with the Exchange 2000 or Exchange Server computer. This might happen if the server became unavailable, or if you were having a cable, network adapter, or some other network problem.

The effect was that when you attempted to send a daily summary or a test message in Outlook Mobile Manager, the connection wizard might have taken an unexpectedly long time to attempt to send the message (as if the system had stopped responding), and then you would most likely have received the following error message: Mobile Manager could not save your changes. Please exit and restart.

If you clicked Help, and then clicked Troubleshooting; the following error message was logged: A MAPI error occurred. (Error Code: 0×80040113)

The description for that error lists error code 1217, which indicates:
The connection to the Exchange server has been lost. There is a network problem or the Exchange server is offline and that you should contact your network administrator.

At this point, you should have exited Outlook Mobile Manager, closed the system tray icon, and then restarted Outlook Mobile Manager. Next you would have tried to reconnect to your Microsoft Exchange 2000 Server or Microsoft Exchange Server computer.

If the problem continued then you could also have tried to resolve it by checking your network connectivity and ensuring that you could still connect to your Exchange 2000 or Exchange Server computer and other network shares. The most basic of network diagnostic tasks is to try a simple “ping” command to check for network connectivity between the client and the server.

Beyond the network diagnostics you could also try restarting Outlook Mobile Manager.

Be forewarned that Microsoft Outlook Mobile Manager has been discontinued and is no longer available for download. If you have already installed Outlook Mobile Manager, you can continue to check the Microsoft Knowledge Base for any documented issues. More information about Microsoft Mobile Information Server can be obtained from the following Microsoft Web site: http://www.microsoft.com/exchange/default.mspx.

I also noted earlier that issuing a command to MSGraph that uses OLE automation could cause the error message: OLE error code 0×80040113 Invalid class string.

As an example you might have tried:  Append General myGeneralFieldName Class “MSGraph

The reason you received an error code was because Microsoft Graph had not been installed or registered to the operating system.

Microsoft Access ships with many smart components including forms and reports, text and combo and list boxes, options groups and the ability to add Active X and OLE components. The most complicated of the standard objects is Microsoft Graph. As MS Graph is part of the standard install process with Access, you will generally find that the object is available on most computers that Access is installed on.

When trying to diagnose the cause of error 0×80040113 you can also turn on diagnostic logging. For more information about how to turn on diagnostic logging you can review the following URL:  http://support.microsoft.com/default.aspx?scid=kb;en-us;Q300479

Note that IMAP and Hotmail accounts generate one log for each Send/Receive action that you perform on these accounts (the log files are named Hotmail0.LOG, Hotmail1.LOG, etc.). If you have multiple Hotmail accounts configured, the folders where the logs are placed are named Hotmail, Hotmail 1, Hotmail 2, etc. You may have to close Outlook for the logs to be written to the log files.

And Dr. Nielsen has a point. It’s often happened to me–I’m typing in a password. I get interrupted for a moment, and wonder whether I typed in the right character. I look at the screen, but since there is nothing there but a row of bullets, I can’t tell. Typing in passwords into smartphones and other mobile devices is especially vexing, since most people’s fingers just aren’t meant for typing on tiny keyboards, and typos are common. And if your admin has done his/her job right, if you make three typos in a row, you’ll get locked out. Having clear-text feedback in the password box would eliminate a lot of these problems and make for easier login.

A SANS response to Dr. Nielsen brings out a few concerns, while acknowledging the usability issue. The SANS response still brings up the objection of shoulder-surfing or even accidental observation, along with the potential problem of autocomplete web forms prefilling passwords along with other information. There may also be some compliance issues.

From a security perspective, eliminating password masking should be approached with caution, but the real security comes in increased password difficulty, and in encryption, not in the masking itself. SANS recommends going further and implementing two-factor authentication, which both increases security and improves usability. The two-factor approach eliminates the need to memorize passwords, which overcomes a lot of objections; and further serves to eliminate the scenario of shoulder-surfing. That is, even if someone looks over your shoulder and sees your password in clear text, it’s useless to them, since the two-factor system generates a new password for every use.

As reported in Forbes this week, an IBM researcher has made some progress towards solving that dilemma. Although there is no current commercial implementation of the solution, the researcher, Craig Gentry, has effectively set the wheels in motion. Gentry has solved the problem of fully homomorphic encryption, which allows the anti-malware analysis, as well as other processes, to be performed directly on encrypted data, without having to decrypt it first. No software is currently able to do that, and in reality, it may be several years before it is commercially available–but it’s nonetheless a big breakthrough in security.

1. when you cannot move, synchronize, or autoarchive messages
2. if active mail session with Exchange server was broken
3. when emailing a report using the tree email from within FRx Report Designer
4. when you use Distributed Authoring and Versioning (DAV) to query for message properties on the information store in Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003

If you are in a situation where you (1) cannot move, synchronize or autoarchive messages then you may receive the error code 0×80040005. When you try to AutoArchive messages, move messages, or synchronize items while Microsoft Outlook is connected to a Microsoft Exchange Server mailbox, you may receive the following error message:

Error while archiving folder <folder name - Inbox> in store “Archive Folders”. The source and destination folders for this operation cannot be the same.

It is possible that you receive the following message in the synchronization log:
12:51:31 Error synchronizing folder   
12:51:31 [80004005-501-0-550]   
12:51:31 The client operation failed.   
12:51:31 Microsoft Exchange Server Information Store
     
You might also receive the following error message when you attempt to copy/move:
“Can’t move the items. The item could not be moved. It was either already moved or deleted or access was denied.”

To resolve this behavior, verify that all items with attachments are either opened or deleted when you receive them.

You can use the Preview pane in Outlook to view the messages. This opens the messages and allows the scan to take place. There may be minor delays in the process while the scans occur.

In the case where (2) active mail session with Exchange server becomes broken - this may happen if xp_sendmail fails with the mail error code 0×80004005.

When you use xp_sendmail extended stored procedure to send e-mail from SQL Mail with SQL Server 2000, you might receive the following error message:
 
Server: Msg 18025, Level 16, State 1, Line 0
xp_sendmail:failedwithmailerror 0×80040005
 
You receive the same error message if you use SQL Server Agent to send email messages. However, when you use the Microsoft Outlook client on a computer that is running SQL Server (and Outlook is configured with the same MAPI profile as SQL Mail), the delivery of messages is not affected and you can successfully send e-mail.

You can experience problems described in the “Symptoms” section of this article if connection to the Microsoft Exchange server was broken during active SQL Mail session. The connection could be broken due to a sudden loss of network connectivity with an Exchange server or because of other network problems. As a result, an invalid SQL Mail session is left on an SQL Server, and SQL Server attempts to utilize it for xp_sendmail calls. Since the mail session is invalid, an error is returned.

To fix the problem without restarting the SQL Server service, you may manually stop the invalid mail session. To do so, connect to the SQL server with Microsoft SQL Server Query Analyzer or similar utility using an account with sysadmin privileges, and run the following command:
 
exec master.dbo.xp_stopmail
 
This will force the broken mail session to quit and allow new sessions to be successfully created during xp_sendmail calls.

Another situation can occur where you receive the 0×80040005 error message, “Send Message Error: -2147467259 - (Collaboration Data Objects) - e_fail (80004005)”

This error occurs when (3) emailing a report using the tree email from within FRx Report Designer.

One of the following should resolve the error:

1. Confirm that the pathing for the Output path in the Company - Information screen and pathing that has been entered in the Catalog - Output tab Filename field is a valid path.
2. When sending an attachment and using the email in the tree, a Mailbox file size limit may be reached. Remove some users from the tree or increase the size limit of the Microsoft Outlook mailbox.

Another possible circumstance when you might receive the error code 0×80040005 is (4) when you use Distributed Authoring and Versioning (DAV) to query for message properties on the information store in Microsoft Exchange 2000 Server or Microsoft Exchange Server 2003. Then the DAV query of the information store for message properties returns the 0×80004005 error code.

A 0×80004005 (ecCallFailed) error is returned if the urn:schemas:mailheader:to property is requested. Additionally, an error is returned if there are messages in the result set that have recipients where the value of PR_EMAIL_ADDRESS is an empty string (”").

To resolve this problem, obtain the latest service pack for Exchange Server 2003. For more information you can review article number, 836993, in the Microsoft Knowledge Base to learn more about how to the latest service packs for Exchange Server 2003.

In addition, a supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem concerning when the DAV query of the information store for message properties returns the 0×80004005 error code.

The Client Access Server Role

Client Access servers perform a similar role to that of “front end” servers in previous versions of Exchange.  The Client Access server is responsible for all non-MAPI connectivity to Exchange server data.  In other words, anything that is not a Microsoft Office Outlook connection to a mailbox or public folder is handled by the Client Access server.  This includes Outlook Web Access, ActiveSync, and Exchange Web Services.

The nature of this role is such that it relies on Microsoft IIS to make these services available.  Because of this the Client Access server is one of the more complex when it comes to backup and recovery.

Backing up the Client Access Server

The data that needs protecting by backup for the Client Access server is located in several places:

• Exchange server configuration stored in Active Directory
• Configuration files stored in the file system (C:\Program Files\Microsoft\Exchange\ClientAccess)
• IIS customizations stored in the IIS metabase

Similar to the Hub Transport server the Exchange server configuration can be recovered from Active Directory using the setup /m:RecoverServer command.  Assuming the Active Directory is already backed up by your Domain Controller backup strategy the Client Access server backups only need to take into account the configuration files in the file system and the IIS metabase.

However there is a downside to this.  When setup /m:RecoverServer is used to restore a Client Access server, and then the IIS metabase is restored afterwards, the Client Access server will experience errors.  Because of this, Microsoft recommends keeping a manual change log of all customizations made to the Client Access server, such as changes to the default virtual directories, or any new virtual directories created.

A workaround for this is to perform a full backup of the file system and System State for Client Access servers.  This allows you to restore the entire server without causing problems after the IIS metabase is recovered.

Recovering the Client Access Server

Since there are two approaches to backing up the Client Access server role there are also two approaches to recovery.

The first is to use setup /m:RecoverServer to reinstall Exchange on the replacement server.  Then, restore the C:\Program Files\Microsoft\Exchange\ClientAccess files from the most recent backup.  Finally, manually apply all customizations that have been recorded in a change log.

The above method will work provided your change log is up to date and accurate.  Any discrepancies will potentially lead the recovery effort astray.  This method is also quite tedious and error prone in complex environments.

The second approach is to use a complete server backup for the restore.  In this scenario the new server is installed with the operating system only.  There is no need to join it to the domain or even to give it a static IP address provided a DHCP server is available.  Next, restore the last full server backup onto the server.  It is likely that the server will then require a restart.

This second approach is less effort and will tend to be more accurate but requires that more data be backed up each night than for the first method.

Recovering Individual Email Items

In Part 2 of this series I demonstrated the recovery of an entire mailbox database.  In some situations it may be necessary to recover just a single email item from a backed up mailbox.  In the next part of this series I will demonstrate how to restore single mailbox items.

Microsoft released a report this week highlighting just how vulnerable the secret question gambit really is. Sure, password resets take up time, but letting end-users retrieve them on their own this way is just a bad idea. Microsoft’s study, which was reported on in the New Scientist, showed that the secret question is often easily guessed. The study looked at webmail users’ acquaintances, and asked them to try to guess the secret question of the webmail user’s account. The acquaintances guessed right about 20 percent of the time.

But you don’t have to know the person to make a good guess. Social networking sites are typically full of personal tidbits of information. What’s your dog’s name? Chances are, if you’re a dog lover, you’ve posted a few pictures of your pooch here and there, and have mentioned the lovable mutt’s name a couple times on your blog, Twitter, or social networking page. It’s easy to find. What was the name of your high school? That’s an easy one to discover. Ever hear of Classmates.com?

The Microsoft study recommends an alternative to the secret question, which involves a user selecting multiple individuals to act as trustees; if the user gets locked out, they ask the trustees to download a recovery code. The user collects the recovery codes, and then can gain access to the account. 

Other times you will receive this error in conjunction with using the MAPI component of ASP. The Mail Application Programming Interface (MAPI) is a component used in Active Server Page (ASP) code. It was formerly called Active Messaging, but is now called Collaboration Data Objects (CDO). To allow for greater functionality from the object library than was available in Active Messaging 1.1, the objects were replaced by CDOs. CDOs are objects that support capabilities beyond simple messaging into the areas of calendaring, collaboration, and workflow.

ASP technology is used very widely in Exchange 2000 conferencing and as a result, you may encounter a variety of MAPI warnings and error messages one of which will be the 0×8004011C error code.

The optimal return value for any call to MAPI is zero, which signifies that the call is successful and is producing the expected results. However, MAPI may return a warning value (CdoW) or an error value (CdoE) to the CDO libraries. A warning signifies a partial success with possible unexpected results or side effects. An error indicates the call was not successful. All warning and error return codes are nonzero.

Such is the case of a returned error code of 0×8004011C (decimal value 1284) -  CdoE_UNCONFIGURED

Sometimes your error received will look something like this:

Event Type: Error
Event Source: MSExchangeAdmin
Event Category: Move Mailbox
Event ID: 1008
Date:  (Date)
Time:  (Time)
User: N/A
Computer: xxxxxxxxxx
Description:
Unable to move mailbox ‘<xxxx>’.
Error: The information store could not be opened.
An unexpected, unknown error has occurred.
MAPI 1.0
ID no: 8004011c-0289-00000000

Another condition for you to receive the error code 0×8004011C is if you receive the message “Your profile is not configured” when you access Client Permissions. This can happen if you are in Exchange System Manager, when you right-click a public folder, click Properties, click the Permissions tab, and then click Client permissions to view the permissions on the public folder. You may receive the following error message:

Your profile is not configured.
An unexpected, unknown error has occurred.
Microsoft Exchange Server Information Store
ID no: 8004011c-0521-00000000

ID no: c1050000
Exchange System Manager

This issue can occur if the mailbox store where the System Attendant mailbox is located is not mounted. To resolve this issue, mount the mailbox store where the System Attendant mailbox is located. If you do not want the System Attendant mailbox to be located on the current mailbox store, you can move it to another mailbox store on the same server.

Another situation when you might receive the error code 0×8004011C is when mailbox logon scripts fail; Exchange 2000 Management Pack components for Microsoft Operations Manager (MOM) 2005 cannot monitor a server that is running Microsoft Exchange 2000 Server. An event that is similar to the following appears in the MOM 2005 Operator Console:

Description:
Cannot verify availability of the following test account:
Exchange Server: “Server Name”
MDB:” Store Name”
Mailbox: “Mailbox Name”
due to the following error
Error ID: 0×80040704(-2147219708)
Error text: Your profile is not configured.
[Microsoft Exchange Server Information Store - [MAPI_E_UNCONFIGURED(8004011C)]]
Computer: Computer Name
Time: Time
Type: Error
Provider Name: Script-generated Data
Event Number: 9983
Provider Type: Generic Provider
Source: Exchange MOM
Category:
Raises Alert: True
Consolidated:
From:
To:
Event Id: EventId

For this situation, a supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described above. Apply this hotfix only to systems that are experiencing this specific problem. There is a “Hotfix download available” section at the Microsoft Knowledge Base.

The “Hotfix download available” form displays the languages for which the hotfix is available. If you do not see your language, it is because a hotfix is not available for that language.

Because of file dependencies, this hotfix requires Microsoft Exchange 2000 Server Service Pack 3 (SP3). For more information, please review the following Microsoft article number, 301378, in the Microsoft Knowledge Base.

The English version of this hotfix has the file attributes (or later file attributes) that are listed in the following table. The dates and times for these files are listed in Coordinated Universal Time (UTC). When you view the file information, it is converted to local time. To find the difference between UTC and local time, use the Time Zone tab in the Date and Time tool in Control Panel.
   Date          Time    Version      Size      File name
   ——————————————————-
   03-Aug-2004   19:12   6.0.6615.0   716,800   Cdo.dll         
   03-Aug-2004   19:10   6.0.6615.0   745,472   Mapi32.dll  

Microsoft has confirmed that this is a problem in Exchange 2000 Server.

When unsuspecting users click on the link, thinking they will get an update to Outlook, they are taken to a rogue Web site that sends a Trojan horse to their computer.

The tricky attackers may actually get some takers, not only because of the realistic-looking email, but also because the notice comes out at about the same time Microsoft really is getting ready to release its monthly security patch.

Like most such bogus emails, the link contained in the email appears to go to Microsoft.com, but looking at the actual HTML (pass your cursor over it and see) will show that it goes somewhere else entirely. If you fall victim, you’ll get a piece of malware that appears to be a variant of Zbot, a Trojan used often to steal login details and take control of computers.

The Apple iPhone may not be the most technologically superior smartphone, but it is the most trendy and cool-looking, and it’s what road warriors ask for. And with the latest iteration of the iPhone now out on the market, that demand is only going to increase. A Silicon.com survey recently asked IT chiefs if they have plans to offer the iPhone, and most responded that they are not. Two out of the 12 panel members said that they would agree to offer it.

When road warriors send and receive email from a smartphone, there are natural security concerns, regardless of which smartphone platform is being used. These include:

1. Is the smartphone secured against malware?
2. Is the user taking advantage of a secure connection (https) to the mail server when checking and sending email?
3. Is there authentication in place?
4. Are there any precautions against physical theft?

More rigorous authentication is needed for remote email, whether it’s from a smartphone or a notebook, simply because of the increased risk of theft. A desktop in the office may typically be configured so that email is automatically checked every 15 minutes, and typically, the user does not have to manually enter the email password to retrieve or send. With a smartphone though, there’s an obvious attraction to a thief, especially if it’s a trendy little goodie like the iPhone. And when they do steal it, if there is no manual password requirement, the thief can get into the owner’s email with no trouble at all.

Sometimes they will try to send an email but get back a message similar to the following: This message could not be sent. Try sending the message again later, or contact your network administrator. The Microsoft Exchange server is currently busy. If this message is still displayed in 30 minutes, contact your Exchange server administrator. Error is
[0x80040111-0x80040111-0x000520].

There are other situations when you may get the error code 0×80040111 such as:

• PRB: Error “ClassFactory Cannot Supply Requested Class” (80040111 …  (279129).
• Attempting to install Microsoft Windows Live OneCare.
• If you have two instances of Microsoft SQL Server 2000 on the same computer, and SQL Mail is configured with separate mail profiles on each instance.
• Move Mailbox operation is unsuccessful.
• Logons to the Microsoft Exchange server computer fail and you get “The information store could not be opened” error message.
• If the MSSQLServer Service startup account is set to the local system account and xp_startmail fails.
• Exchange 2000 Management Pack MAPI Logon Check Reports Logon Failures.

Sometimes you receive fatal error messages when you use the MsExchange Event Services (Events.exe) in Exchange Server 5.5 or in Exchange 2000 Server to process messages. This can happen when a client action spawns activation of a script and they get the following error message:

A fatal error (0×80040111) occurred in an IExchangeEventSink while processing message [Subject = "xxx"]

This is a MAPI error which translates to the MAPI_E_LOGON_FAILED error value.

This issue may occur if any one of the following conditions are true:

• At least one script was last modified by someone who shares the same alias, the same surname, or the same display name as someone else in the global address list.
• For an Exchange 2000 Server-based computer, the Exchange Event Service logs on as the local computer account instead of a service account.
• If you join an Exchange 2000 Server-based computer to the site, and then perform either of the following actions:
  o Move the mailbox that created the event scripts that are bound to a folder.
  o Move an existing Exchange Server 5.5 script to an Exchange 2000 Server-based computer.

You should first determine if there is a duplicate mailbox alias (Mixed or Pure Exchange environments). You can do this by following the steps listed below. (Remember to always backup your Registry.)

1. Determine which mailbox has a duplicate alias by clicking on the EventConfig_servername folder for the server that is receiving the errors, then see who has Owner permissions. Do this because only the owners can modify the scripts.
2. Look for duplicate names by sending a new message to the alias, and then perform a check name procedure. If more than one mailbox is returned, check the surnames to see if there are duplicates.
3. To check for ambiguity for each of those aliases:
   o Type their alias in the To line of the client and perform a Check Name.
   -Or-
   o Type =alias on the To line, then press ALT+K.
   -Or-
   o Perform a directory export of the global address list and sort on the Alias column to see if any of the owners of the EventConfig_servername folder shows multiple listings.
4. Set diagnostic logging to Maximum (5) for the Event Service. This can only be done in the registry at:
   HKEY_Local_Machine/System/CurrentControlSet/Services/MSExchangeES/Parameters

If no duplicate mailbox aliases were discovered then you should resolve known issues with permissions (Mixed or Pure Exchange environments).

If duplicate mailbox aliases were discovered then you have to decide whether you want to choose a different (unique) mailbox to edit the scripts or remove the other mailboxes from the global address list.

If the scripts are installed in mailbox folders, the next part is even more detailed if you do not have a list of which mailboxes have scripts associated with them or there are many that do. This is because even with Event Service logging turned up to Maximum (5) in the registry, the Event ID 16385 (which occurs just before the Event ID 11) says that the folder being processed is Inbox. Every mailbox has an Inbox folder. So you cannot know which mailbox has been altered by the “rogue” EventConfig owner.

1. Post or send a message to the above mailboxes in a segmented fashion to determine when the Event ID 11 occurs. Twenty percent intervals during a quiet time in the environment are suggested.
2. When you find the mailbox, simply go into the script and save it while you are logged on as a unique mailbox alias.
3. If the scripts are installed in public folders:

• Set Event Service logging to Maximum (5) in the registry.
• Post or send messages to the public folders in the same fashion as described with mailboxes above, and monitor the application log.
• Event ID 16385 tells you which folder it is processing and, in case there are multiple agents in the folder, Event ID 32773 tells you the agent that it’s calling.
• Log on to a unique mailbox that has Owner permissions on the EventConfig_servername and the public folder, then open the script, and save it.

Backing up Transport Servers

Unlike Mailbox Servers, the Hub Transport and Edge Transport roles do not require any special Exchange-aware backup software.  All of the necessary data for recovering a Transport server is contained within:

• Active Directory (for Hub Transport servers, but not Edge Transport servers)
• The Active Directory Application Mode (ADAM) database (for Edge Transport servers)
• The server’s file system
• The server’s System State

Hub Transport servers can be backed up using the built in Backup utility in Windows Server.  At the very least the backup should include the System State and the C:\Program Files\Microsoft\Exchange Server\TransportRoles location of the file system (and all sub directories).

Edge Transport servers are backed up in the same way as Hub Transport servers except for the Exchange Server configuration.  Because this is stored in ADAM it must first be cloned using the Export-EdgeConfig.ps1 script located in C:\Program Files\Microsoft\Exchange Server\Scripts.  Execute the script with the name of the file you wish to export to. Note this is a single command run on one line in the Exchange Management Shell.

export-edgeconfig.ps1 c:\edgeconfig.xml
 -key "abcdefghijklmnop"

It is recommended to either include this config file in your Edge Transport backups or use a path that is a shared folder on a remote server.

Recovering Hub Transport Servers

In this scenario the EXCHHUB server has been lost due to hardware failure.  Spare server hardware has been used to reinstall Windows Server 2003 along with the Exchange Server 2007 pre-requisites.  The newly built server has the same name and IP address of EXCHHUB.  Now we can begin the recovery of the Hub Transport server.
First, remove any Edge Subscriptions that existed for the Hub Transport server being recovered.  If you skip this step you may receive a certificate error during the recovery install.

In a command prompt run the following command from the location of the Exchange setup files.

setup /m:RecoverServer /DoNotStartTransport

This runs setup in recovery mode along with an additional instruction to not start the Transport services straight away.  This is so we can restore our mail queue databases and log files from the most recent backup before the server is put back into operation.

Recovering Edge Transport Servers

In this scenario the EXCHEDGE server has been lost due to hardware failure.  As with the Hub Transport server a new server and operating system has been installed with the same name and IP address.

To recover the Edge Transport server we will use the ImportEdgeConfig.ps1 script that ships with Exchange Server 2007.  First we run the script against the exported Edge config file from earlier to validate its contents. Note, this command is all one line.

ImportEdgeConfig.ps1 -cloneConfigData c:\edgeconfig.xml
 -isImport $false -CloneConfigAnswer c:\configanswer.xml
 -key "abcdefghijklmnop"

Validation succeeded for ConnectivityLogPath element of
 type DirectoryPath
Validation succeeded for MessageTrackingLogPath element of
 type DirectoryPath
Validation succeeded for PickupDirectoryPath element of
 type DirectoryPath
Validation succeeded for PipelineTracingPath element of
 type DirectoryPath
Validation succeeded for ReceiveProtocolLogPath element
 of type DirectoryPath
Validation succeeded for ReplayDirectoryPath element of
 type DirectoryPath
Validation succeeded for RoutingTableLogPath element of
 type DirectoryPath
Validation succeeded for RootDropDirectoryPath element of
 type NullableDirectoryPath
Validation succeeded for SendProtocolLogPath element of
 type DirectoryPath
Validation succeeded for SourceIPAddress element of
 type IPAddress
Validation succeeded for SourceIPAddress element of
 type IPAddress
Validation succeeded for Bindings element of type Bindings
Validation succeeded for Fqdn element of type FQDN
Answer File is successfully created: c:\configanswer.xml

Note that the key is the same one used when the Edge config was exported earlier.  If any validation steps were unsuccessful open the answer file in a text editor and adjust the settings that it lists as invalid.

Once the config has been validated it can be imported with the same command but modifying the -isImport parameter to $true. Note again this is a single command.

ImportEdgeConfig.ps1 -cloneConfigData c:\edgeconfig.xml
 -isImport $true -cloneConfigAnswer C:\configanswer.xml
 -key "abcdefghijklmnop"

Importing Edge configuration information Succeeded.

Now that the Edge Transport server configuration has been restored you can re-create the Edge subscription between the Edge Transport and Hub Transport servers.

How to Back Up and Restore Client Access Servers

In the final part of this series I will demonstrate the process of backing up Client Access servers and then recovering them from failure.

The city’s background check policy required applicants to provide login details, including passwords, for all social networking sites they belong to. The requirement, which is included on a waiver statement, asks applicants to “Please list any and all current personal or business websites, web pages or memberships on any Internet-based chat rooms, social clubs or forums, to include, but not limited to: Facebook, Google, Yahoo, YouTube.com, MySpace, etc.” Forcing applicants to turn over their passwords, especially for Google and Yahoo, may even cause the applicants’ personal email to be vulnerable to snooping as well. Bozeman’s City Attorney defended the policy in true lawyerly fashion, claiming the policy was necessary to protect the public trust.

Is it necessary? Companies do conduct background checks on potential employees, and are justified in doing so. It is of course, very common for potential employers to check out a job candidate’s cyber-background, conducting a quick search on Google and on various social networking sites. For potential employees, anything you have posted publicly is fair game for the background check. But requesting passwords is over the top and is just too egregious of a privacy violation to stand. There’s no excuse for it and no justification.
 
Days after the news broke and the blogosphere showed its outrage, the city revoked the policy, probably out of embarrassment for even having thought up this stinker of an idea in the first place.

There’s a fine line that Bozeman crossed here, and policies like this could very easily lead to cracking into personal email accounts. It’s one thing for a job applicant to post on a public social networking site “I just interviewed at XYZ company, and the boss is a pointy-haired idiot.” Said pointy-haired idiot can legitimately look at that public post, since it is, well, public. If you lose out on a job after making a post like that, you got what you had coming to you for being stupid enough to post it. But, if the applicant writes a personal email and says the same thing, then that’s another matter, and the hiring manager has no business looking at it. The fine line is made even finer, since it has been generally accepted as legitimate for companies to read employee email sent through the company server, so long as the employee is aware of the policy.

When they try to sync with MS Exchange Server 2003 using Windows Mobile 5.0 they might get the following error code: 0×80072f17. Some users have also reported problems when trying to sync with MS Exchange Server 2007.

This problem is usually associated with using Secure Socket Layer (SSL) certificates.

Remember that you use SSL for Internet protocols such as Network News Transfer Protocol (NNTP), Simple Mail Transfer Protocol (SMTP), Post Office Protocol version 3 (POP3), and Internet Message Access Protocol (IMAP).

The SSL authentication method uses public/private key technology to ensure privacy. The SSL protocol resides at the Open Systems Interconnection (OSI) presentation layer and moves data from the application layer to the TCP transport layer. It is responsible for authentication, encryption, and verification of data integrity.
The authentication function assures that the data is being sent to the correct server and that the server is secure. Encryption ensures that data cannot be read by anyone other than the target server. Data integrity ensures that the data has not been corrupted or altered in transit.

If your user removes the SSL authentication then they’ll probably be able to synchronize their phones with the server. But that’s probably not how you want them to operate. Even if you directly install the certificate you may still have problems. Checking or un-checking the proxy settings related box does not have an effect on the problem.

One solution to this problem is to reissue the SSL certificate through Internet Information Services (IIS). This can happen if you were using the original certificate the Exchange Server installed and the certificate was replaced.

Another possible cause for the 0×80072f17 error is if an unsupported certificate has been installed. If you installed a certificate that supported wildcards from a certifying digital certificate provider, then this certificate will probably install but using the certificate was most likely not supported. To fix this problem you can replace the certificate with one that does not use wildcards and is listed in the root certificate store on the device.

Another situation when the problem can occur is when Microsoft Exchange does not connect but generates another error code: 0×80072EE7. Selecting another system to synchronize with will result in a related synchronization error message such as when the Microsoft Exchange server shows “Synchronization could not be completed. Try again later”. The support code generated by the system is: 0×80072F17.

You might need to add a new certificate to your device. Such as when your SSL certificate issuer on the Exchange Server is new to the business or has made some changes.

Here’s how you can enable and disable Outlook Web Access for internal clients:

If you are using Microsoft Exchange Server 2003 Service Pack 1 (SP1), the following steps do not apply. The Web DAV address check is not present in Microsoft Exchange 2003 Service Pack 1.

To restrict access to Outlook Web Access if you are using Exchange Server 2003 SP1 or later, follow these steps:

1. In the Active Directory Users and Computers snap-in, right-click the user account that you want to restrict from using OWA, and then click Properties.
2. Click the Exchange Features tab, click Outlook Web Access, and then click Disable.

By default, user accounts that are mailbox-enabled are also enabled for Outlook Web Access in Exchange Server 2003.

You can enable users in your corporate network to access Outlook Web Access. At the same time, you can deny access to external clients. The key to this approach is a combination of a recipient policy and a special Hypertext Transfer Protocol (HTTP) virtual server.

To use this approach, follow these steps:

1. Create a recipient policy with a Simple Mail Transfer Protocol (SMTP) domain name. Users who connect to an HTTP virtual server must have an e-mail address with the same SMTP domain as the virtual server. Creating a recipient policy is an efficient way to apply the same SMTP domain to multiple users. (Note Outlook Web Access users do not have to know the name of the SMTP domain.)
2. Apply the recipient policy to the user accounts that you want to enable access for.
3. On the front-end server, create a new HTTP virtual server that specifies the domain that is used in the recipient policy.

After you have completed these steps, users whose e-mail addresses do not have the same SMTP domain as the HTTP virtual server cannot log on and access Outlook Web Access. Also, as long as you do not use the SMTP domain as the default domain, external users cannot determine what the SMTP domain is because the domain does not appear in the From field when users send e-mail messages outside the organization.

For more information, review the following article number in the Microsoft Knowledge Base:  293386  HTTP 401 or 404 error messages when you access OWA implicitly or explicitly.

Besides enabling Outlook Web Access for users in your corporate network, you can also prevent specific internal users from accessing Outlook Web Access. You do this by disabling the HTTP and Network News Transfer Protocol (NNTP) protocols for those users.

To prevent an internal user from accessing Outlook Web Access, follow these steps:

1. In the Active Directory Users and Computers snap-in, open the user’s Properties dialog box.
2. On the Exchange Features tab, click Outlook Web Access, and then click Disable.
3. Restart the IIS Admin Service.

The old argument, often eliciting strong response, really highlights the difference between the hype and reality. Now every computer company is guilty of a little hype. That’s the job of the marketing department, and they wouldn’t be doing their jobs if there wasn’t at least a little hype surrounding a product at any given time. Apple does it, Microsoft does it, and so does everybody else. That’s how products get sold. But in the case of Apple, far too many people have bought into the party line, and there could be a long-term danger as a result. Here’s the conflict: Mac fans believe that the Mac is absolutely secure and requires no anti-virus or email security software of any kind. Security experts generally have always disagreed, and even Apple itself has reiterated its own suggestion that users deploy anti-virus software. But still the faithful cling to their illogical contention that “it can’t happen to me because I have a Mac.”

Now here’s the reality. Yes, OS X is a good operating system, and the Mac is a pretty good machine. For the most part, it has fewer vulnerabilities and less attacks. But there’s a big difference between that reality, and the claim that “it can’t happen to me because I have a Mac.” That claim is just hype.

In fact, it can happen to you, and it will probably continue happening to you with increasing frequency. Just this month, an updated piece of malware targeting the Mac OS X was found; a new variant of Jahlav, as well as a new variant of Tored, which is being used in an attempt to create a Mac-based botnet. The lure of money will continue to attract bad guys to the OS X platform.

Google continues to try to get a seat at the enterprise with Gmail, and this week, some of the industry’s heavy-hitters took Google to the task over the issue. An open letter to Google’s CEO Eric Schmidt says the company is putting users at risk unnecessarily, and that encryption should be enabled by default on their web-based apps, including Gmail.

Currently, SSL is used only during login, after which, all browsing is unencrypted, unless the user takes an active step to return to the https protocol. Unless that step is taken, which most users will not do, the user is vulnerable to attack and theft. In most cases then, Gmail is run in the clear–which is completely unsuitable for corporate use.

Sometimes you receive the 0×85010004 error message when you try to synchronize a Windows Mobile 5.0-based device in Exchange Server 2003.

You may have installed Microsoft Exchange Server 2003 Service Pack 2 (SP2) on a computer that was running Microsoft Windows 2000 Service Pack 4 (SP4). And you enabled the Enforce password on a device option in Exchange System Manager. This option is in the Device Security Settings dialog box under Mobile Device Properties. Then you tried to synchronize a device that was running Microsoft Windows Mobile 5.0 software for Pocket PCs. If that device had the Messaging and Security Feature Pack for Windows Mobile 5.0 installed you probably received the following error message: 0×85010004. The device probably also did not synchronize.

An additional error message may show up on your Windows Mobile-based device:

“Your Account does not have permissions to sync with your current settings. Contact your Microsoft Exchange administrator.  Error code: HTTP_403”

When this error happens the device security settings will not be enforced on Windows Mobile-based devices. The device security settings, set in the global settings of the Exchange server, will be bypassed even though the mobile device will still synchronize.

A supported hotfix is available from Microsoft. However, this hotfix is intended to correct only the problem that is described here. Only systems which are experiencing this specific problem should have the hotfix applied. Additional testing was still planned for this hotfix so if you are not severely affected by this problem it is recommended that you wait for the next software update that contains this hotfix.

Prerequisites for this hotfix include SP2 be installed for Exchange Server 2003. The following services will need to be restarted after you apply the hotfix:

• World Wide Publishing Service
• Simple Mail Transport Protocol (SMTP)
• Microsoft Exchange Routing Engine
• IIS Admin Service

Another 85010004 error code message may look like this:

HTTP_403 85010004 : A forbidden HTTP communication or protocol was used.
- OR -
Your account does not have permission to sync with your current settings. Contact your Microsoft Exchange administrator. Remove the item from the synchronization list.

In this case, you may have one of three possible scenarios:

1. The Microsoft-Server-ActiveSync virtual directory on your server is configured to require SSL and you are using a device without SSL.
2. The Exchange virtual directory on your mailbox server is configured to require SSL.
3. This error could occur if host headers are being used and the request goes to the wrong Web site.

Here are possible solutions:

1. On your Pocket PC 2003-based device, click Start, ActiveSync, Tools, Options, Server and check the box “This server uses an SSL connection”.
2. On your Smartphone 2003-based device, click Start, ActiveSync, Menu, Options, Server Settings, Connection and check the box “This server uses an SSL connection”.
3. Verify that host headers are configured correctly.

Here are some additional troubleshooting steps you can take:

1. Install the hotfix already mentioned above.
2. This issue can be caused if you have a Firewall and have not allowed a rule on the Firewall for Microsoft-Server-ActiveSync:

• Check if you have run the CEICW Wizard
• Open Server Management console, navigate to ‘To Do List’ and click ‘Connect to the internet’ in the right panel.
• Run the wizard to configure the networking settings for a SBS server. It automatically creates the ISA rules for internet access and site publishing. It’s strongly recommended to use the wizard to configure the SBS server. More info can be found in the article 825763 - How to configure Internet access in Windows Small Business Server 2003 - http://support.microsoft.com/?id=825763
  This can help in situations where you are unable to synchronize with Exchange server using Active Sync.  (http://support.microsoft.com/default.aspx?scid=kb;EN-US;924216)

1. Check the properties of Microsoft-Server-ActiveSync. The Directory Security properties for the IP Address and Domain Name Restrictions should be set to “GRANTED ACCESS” and not configured as ” DENIED ACCESS”.
   a. Open IIS.
   b. Expand Web Sites -> Default Web Site.
   c. Open the Properties page of Microsoft-Server-ActiveSync.
   d. In Directory Security tab, click Edit under “IP address and domain name restrictions”.
   e. Make sure that you configured as Granted access.
2. Check the following IIS settings:

• For Exchange/Exchange-OMA virtual directory:
  a. Open IIS Manager
  b. Open properties of virtual directory Exchange/Exchange-oma
  c. Select Directory Security tab
  d. Select Edit in Authentication and access control box. Make sure the authentication setting are as follows:
  - Authentication Methods
  - Enabled Basic authentication
  - Enabled Integrated Windows authentication
  - Disabled anonymous access
• For OMA virtual directory and Microsoft-Server-ActiveSync virtual directory:
  a. Open IIS Manager
  b. Open properties of OMA virtual directory and Microsoft-Server-ActiveSync virtual directory respectively.
  c. Select Directory Security tab
  d. Select Edit in Authentication and access control box. Make sure theauthentication settings are as follows:
  - Authentication Methods
  - Uncheck Enable anonymous access
  - Uncheck Integrated Windows authentication
  - Check Basic authentication