A corrupted calendar configuration was detected for user %1. Microsoft Exchange is resetting the configuration.

Details
Product: Exchange
Event ID: 59
Source: MSExchange OWA
Version: 8.0
Symbolic Name: CorruptCalendarConfiguration
Message: A corrupted calendar configuration was detected for user %1. Microsoft Exchange is resetting the configuration.
   
Explanation

This Error event indicates that the user’s calendar is corrupted or has been infected by a virus.

   
User Action

To resolve this error, contact Microsoft Customer Support. For information about how to contact support, visit Microsoft Help and Support.

If you are not already doing so, consider running the tools that Microsoft Exchange offers to help administrators analyze and troubleshoot their Exchange environment. These tools can help you make sure that your configuration is in line with Microsoft best practices. They can also help you identify and resolve performance issues, improve mail flow, and better manage disaster recovery scenarios. Go to the Toolbox node of the Exchange Management Console to run these tools now. For more information about these tools, see Toolbox in the Exchange Server 2007 Help.

Related:

The File Replication Service paused because the staging area is full. Replication will resume if staging space becomes available or if the staging space limit is increased. The current value of the staging space limit is %1 KB. To change the staging space limit, run regedt32. Click on Start, Run and type regedt32. Click on the window entitled HKEY_LOCAL_MACHINE. Double click on SYSTEM, CurrentControlSet, Services, NtFrs, Parameters, and the value “Staging Space Limit in KB”.

Details
Product: Windows Operating System
Event ID: 13522
Source: FRS
Version: 5.0
Symbolic Name: EVENT_FRS_STAGING_AREA_FULL
Message: The File Replication Service paused because the staging area is full. Replication will resume if staging space becomes available or if the staging space limit is increased. The current value of the staging space limit is %1 KB. To change the staging space limit, run regedt32. Click on Start, Run and type regedt32. Click on the window entitled HKEY_LOCAL_MACHINE. Double click on SYSTEM, CurrentControlSet, Services, NtFrs, Parameters, and the value “Staging Space Limit in KB”.
   
Explanation

Modified files are temporarily stored in the staging area before being propagated to other replication partners or when received from them. To replicate files, File Replication Service (FRS) requires adequate staging area space on both upstream and downstream computers. There are four common reasons why the staging area might be full:

  • One or more downstream partners are not accepting changes because the connection schedule is turned off temporarily and FRS is waiting for it to turn back on, because the connection schedule is turned off permanently, or because the downstream partner is in an error state.
  • The rate of change in files exceeds the rate at which FRS can process them.
  • There are no obvious changes made, but the staging area is filling up anyway.
  • A parent directory for a large number of changes is failing to replicate, so all changes below it are blocked.
   
User Action

Follow the steps given in the message for increasing the size limit of the staging area. If the problem continues after the limit is increased, investigate other sources that might cause excessive numbers of staging files to be generated. Some potential sources are programs such as anti-virus or disk defragmenter software.

If space on the volume is low, advanced users can reconfigure the staging path using the following registry key:HKLM\System\CurrentControlSet\Services\NtFrs\Parameters\Replica Sets\ parameter “Replica set stage”

Usually, the default 660-MB limit for the staging area should be increased to approximately 1.5 GB, which is the size of the 128 largest files in the replica.

Related:

%1 (%2) %3An attempt to read from the file “%4” at offset %5 for %6 bytes failed after %10 seconds with system error %8: “%9”. The read operation will fail with error %7. If this error persists then the file may be damaged and may need to be restored from a previous backup.

Details
Product: Exchange
Event ID: 481
Source: ESE
Version: 8.0
Symbolic Name: OSFILE_READ_ERROR_ID
Message: %1 (%2) %3An attempt to read from the file “%4” at offset %5 for %6 bytes failed after %10 seconds with system error %8: “%9”. The read operation will fail with error %7. If this error persists then the file may be damaged and may need to be restored from a previous backup.
   
Explanation

This Warning event indicates that an unexpected error occurred while reading the file specified in the message. ESE Event ID 481 refers to a failed read attempt from the database. For comparison, ESE Event ID 482 refers to a failed write operation to a log file or a database.

The cause depends on the error number in the Description section of the event. The most common error codes for event 481 are as follows:

  • Error -1022 = 0xfffffc02 = 4294966274 = Jet_errDiskIO = Disk I/O error. The -1022 error is a generic error that appears whenever a disk I/O problem prevents Exchange from gaining access to a requested page in the database or to a check file. A disk or controller failure may have occurred, and access to the entire drive has been lost, sometimes temporarily. Check the System log for I/O or drive errors near the time of the 490 event. This issue may occur because the path for the check file (such as E00.chk) is not correct, which may be caused by a drive failure.

  • Error -1811 = 0xfffff8ed = Jet_errFileNotFound = File not found. The database may be missing or there may be other causes for this error. Another reason for error -1811 could be that the Exchange database and log files may have been put on network storage, which is not supported. Also, the checkpoint file may be corrupt, or the log drive itself may have failed. Exchange will disconnect from the storage group due to an inability to locate the database files. Typically, this is due to a hardware problem.

  • Error -1011 = 0xfffffc0d = Jet_errOutOfMemory = Out of Memory. This error indicates that there is no more available memory and the read operation has failed. Other ESE events with out-of-memory errors in the Description section for reading the header of a database, recovery/restore, and starting a storage group are often seen in the application event log at the same time. Review these events for further information.

  • Error -1003 = 0xfffffc15 = Jet_errInvalidParameter = Incorrect API parameter. This error generally means that the file size of the database is not a multiple of 4,096 bytes.

   
User Action

To resolve this warning, do one or more of the following:

  • Review the disk and file that you are trying to read. Check the integrity of the file system. Check the memory usage. Check the system portion of the event log for related entries. Review and change the access permissions properties and then note the disk space available. Check the file size of the database in bytes.

  • For error -1022, check to ensure that the drive for the Exchange store files is accessible and that the path for the Exchange store files is specified correctly. If it is, run chkdsk /f /r. If chkdsk does not resolve the issue, examine the permissions on the C:\Program Files\Microsoft\Exchange Server folder, where C:\ is the directory to which you installed Exchange 2007. Ensure that System has full control of the Exchange Server folder and all subfolders on each partition that contain Exchange data. If you still cannot mount the databases, troubleshoot any Windows NT file-level antivirus software running on the Exchange server. Check the System log for I/O or drive errors near the time of the 413 event.

  • For error -1811, ensure that the antivirus software is not running against the Exchange store, the SRS database directories. Make sure that you have properly configured your antivirus software. For more information, see the Microsoft Knowledge Base article 328841, Exchange and Antivirus Software.

  • Ensure that the database drive has not run out of space. Ensure that the database file is where it is supposed to be.

  • For error -1011, check the memory usage of the server. Check the settings for the page file. Check for memory-related events in the application event log and in the System log and check the Microsoft Knowledge Base for troubleshooting of the events found. For error -1003, check the size of the database in bytes. It must be a multiple of 4,096 bytes, or 1 page. If it is not, contact Microsoft Product Support Services.

  • For information about ESE error codes other than the ones explained in this topic, see the following Microsoft Knowledge Base articles:

If you are not already doing so, consider running the tools that Microsoft Exchange offers to help administrators analyze and troubleshoot their Exchange environment. These tools can help you make sure that your configuration is in line with Microsoft best practices. They can also help you identify and resolve performance issues, improve mail flow, and better manage disaster recovery scenarios. Go to the Toolbox node of the Exchange Management Console to run these tools now. For more information about these tools, see Toolbox in the Exchange Server 2007 Help.

Related:

%1 (%2) %3An attempt to open the file “%4” for read only access failed with system error %6: “%7”. The open file operation will fail with error %5.

Details
Product: Windows Operating System
Event ID: 489
Source: ESENT
Version: 5.2
Symbolic Name: OSFS_OPEN_FILE_RO_ERROR_ID
Message: %1 (%2) %3An attempt to open the file “%4” for read only access failed with system error %6: “%7”. The open file operation will fail with error %5.
   
Explanation

An error occurred while a file was being opened.

Probable causes include:

  • The file is locked or in use.
  • A virus checker might have mistakenly quarantined a file, or a backup process might have temporarily denied access.
  • A flat file backup system or anti-virus software might be running against the database, the check file directories, or the M drive.
  • The permissions on the folder (such as MDBDATA) that contains the files for the information stores are not sufficient for the stores to function correctly.
  • A disk input/output (I/O) problem prevented access to a requested page in the database or to a check file. A disk or controller failure may have occurred, and access to the entire drive was lost, perhaps temporarily. This issue can occur when the path for the check file (such as E00.chk) is not correct.
  • The path for the log files or the check file was changed before the system was restored.
  • The check file (such as E00.chk) is corrupted.
   
User Action

To solve this problem, do one or all of the following:

If the file is locked or in use:

  • Change the permissions on the folders that contain the information store files to the default permissions.
  • Configure the flat file backup and anti-virus software to not scan the Windows Information Store subdirectories or the M drive.
  • Use an online backup and anti-virus software.

If there is an Input/Output problem, do one or all of the following:

  • Run chkdsk /f /r at the command prompt.
  • Examine the permissions on the folder structure.
  • Troubleshoot any file-level antivirus software running.
  • Check the System Log in Event Viewer for any related I/O or drive events.
  • Check and correct the path for the check file (such as E00.chk).
  • Correct the root cause, and then restore from online backup, if there is a recent backup.

If the path was changed:

  • Move the Information Store files back to their original locations and then try to restore again.
  • If the .chk file is corrupt, you may be able to remove it and read all the transactions into the database. If the database remains inconsistent, then restore from online backup if there is a recent version.

For more information about this event, see article Q823022 in the Microsoft Knowledge Base.

Related:

Tactical Cyber Security Checklist

7 best practices to keep your organization cyber resilient and ready for battle

Background Image on Blogs “Quilted” Page: 
Twitter Card Style: 

summary

“If you know the enemy and know yourself, you need not fear the result of a hundred battles. If you know yourself but not the enemy, for every victory gained you will also suffer a defeat. If you know neither the enemy nor yourself, you will succumb in every battle.” Sun Tzu.

Sun Tzu’s words still resonate today. Organizations who know their adversaries, while being aware of their own strengths and vulnerabilities, stand a better chance in the ongoing cyber security war. Don’t wait until after your organization has been attacked to bolster your security posture. Go on the offensive against attackers. 

What are some measures to ensure your organization is cyber resilient and ready for battle? We created the following tactical cyber security checklist based on best practices from the 2016 Internet Security Threat Report (ISTR), our annual report which provides an overview and analysis of the year in global threat acitivity. 

ccs-checklist1-808x808.png

  1. Ensure all devices allowed on company networks have adequate security protections.
    Use active monitoring and configuration management to maintain an up-to-date inventory of devices connected to the enterprise network. This includes servers, workstations, laptops and remote devices.
     
  2. Implement a removable media policy.
    Where practical, restrict unauthorized devices such as external portable hard-drives and other removable media. Such devices can both introduce malware and facilitate intellectual property breaches, whether intentional or unintentional. If external media devices are permitted, automatically scan them for viruses upon connection to the network and use a data loss prevention (DLP) solution to monitor and restrict copying confidential data to unencrypted external storage devices.
     
  3. Be aggressive in your updating and patching.
    Update, patch, and migrate from outdated and insecure browsers, applications, and browser plug-ins. This also applies to operating systems, not just across computers, but mobile, ICS, and IoT devices as well. Keep virus and intrusion prevention definitions at the latest available versions using vendors’ automatic updates. Most software vendors work diligently to patch exploited software vulnerabilities; however, such patches can only be effective if adopted in the field. Wherever possible, automate patch deployments to maintain protection against vulnerabilities across the organization.
     
  4. Enforce an effective password policy.
    Ensure passwords are strong and at least 8 -10 characters long with a mixture of letters and numbers. Encourage users to avoid re-using the same passwords on multiple websites, and sharing of passwords with others should be forbidden. Passwords should be changed regularly—at least every 90 days.
     
  5. Ensure regular backups are available.
    Create and maintain regular backups of critical systems, as well as endpoints. In the event of a security or data emergency, backups should be easily accessible to minimize downtime of services and employee productivity.
     
  6. Restrict email attachments.
    Configure mail servers to block or remove email that contains file attachments that are commonly used to spread viruses, such as .VBS, .BAT, .EXE, .PIF, and .SCR files. Enterprises should investigate policies for PDFs that are allowed to be included as email attachments. Ensure that mail servers are adequately protected by security software and that email is thoroughly scanned.
     
  7. Ensure that you have infection and incident response procedures in place.​​
  • Keep your security vendor contact information handy, know who you will call, and what steps you will take if you have one or more infected systems.
  • Ensure that a backup-and-restore solution is in place in order to restore lost or compromised data in the event of successful attack or catastrophic data loss.
  • Make use of post-infection detection capabilities from web gateway, endpoint security solutions and firewalls to identify infected systems.
  • Isolate infected computers to prevent the risk of further infection within the organization, and restore using trusted backup media.
  • If network services are exploited by malicious code or some other threat, disable or block access to those services until a patch is applied.

While you check off these best practices, be sure to also test, test, and test. Are your security solutions updated regularly? Do you know how your team will respond in the event of a data breach? It’s important to constantly test not only your security technology but also the teams that manage the solutions to stay ahead of threats. 

Related: