Vghd Program Management
You can use Log File Viewer in SQL Server Management Studio to access information about errors and events that are captured in the following logs:
Audit Collection
Data Collection
Database Mail
Job History
SQL Server
SQL Server Agent
Windows events (These Windows events can also be accessed from Event Viewer.)
Beginning in SQL Server 2012 (11.x), you can use Registered Servers to view SQL Server log files from local or remote instances of SQL Server. By using Registered Servers, you can view the log files when the instances are either online or offline. For more information about online access, see the procedure 'To view online log files from Registered Servers' later in this topic. For more information about how to access offline SQL Server log files, see View Offline Log Files.
You can open Log File Viewer in several ways, depending on the information that you want to view.
Permissions
To access log files for instances of SQL Server that are online, this requires membership in the securityadmin fixed server role.
To access log files for instances of SQL Server that are offline, you must have read access to both the RootMicrosoftSqlServerComputerManagement10 WMI namespace, and to the folder where the log files are stored. For more information, see the Security section of the topic View Offline Log Files.
Security
Requires membership in the securityadmin fixed server role.
View Log Files
To view logs that are related to general SQL Server activity
In Object Explorer, expand Management.
Do either of the following:
Right-click SQL Server Logs, point to View, and then click either SQL Server Log or SQL Server and Windows Log.
Expand SQL Server Logs, right-click any log file, and then click View SQL Server Log. You can also double-click any log file.
The logs include Database Mail, SQL Server, SQL Server Agent, and Windows NT.
To view logs that are related to jobs
In Object Explorer, expand SQL Server Agent, right-click Jobs, and then click View History.
The logs include Database Mail, Job History, and SQL Server Agent.
To view logs that are related to maintenance plans
In Object Explorer, expand Management, right-click Maintenance Plans, and then click View History.
The logs include Database Mail, Job History, Maintenance Plans, Remote Maintenance Plans, and SQL Server Agent.
To view logs that are related to Data Collection
In Object Explorer, expand Management, right-click Data Collection, and then click View Logs.
The logs include Data Collection, Job History, and SQL Server Agent.
To view logs that are related to Database Mail
In Object Explorer, expand Management, right-click Database Mail, and then click View Database Mail Log.
The logs include Database Mail, Job History, Maintenance Plans, Remote Maintenance Plans, SQL Server, SQL Server Agent, and Windows NT.
To view logs that are related to audits collections
In Object Explorer, expand Security, expand Audits, right-click an audit, and then click View Audit Logs.
The logs include Audit Collection and Windows NT.
To view logs that are related to audits collections
In Object Explorer, expand Security, expand Audits, right-click an audit, and then click View Audit Logs.
The logs include Audit Collection and Windows NT.
See Also
Log File Viewer
SQL Server Audit (Database Engine)
View Offline Log Files
In today’s information- and data-driven business world, email is more than just a production tool, it is a necessity. Every day, billions upon billions of emails are sent back and forth to businesses all over the world. It is because of this that many of the top messaging solution providers have set their products to support individual mailbox limits in the hundreds of gigs, if not terabytes — or, dare I say, unlimited.
Perfect, right? That means we can save everything and anything in our email — just in case we ever need it. Well, not exactly. There are several things to consider when it comes to using and managing a huge mailbox. Limits need to be in place and policies on what to retain and for how long need to be determined as well.
Mailbox Complexities
Let’s start with your organization’s service level agreement (SLA). Without a limit on your end-user mailbox, it is extremely difficult for an administrator in your IT department to stay within the company’s SLA, let alone come up with one. Mail restores might take hours, if not days, to bring a mailbox back after accidental deletion or corruption.
Another significant pain point is in situations where you get your legal department pressuring you to quickly get an e-discovery search done on a user’s mailbox. It is hard to tell the legal folks that the search could take an extremely long time if they are required by law to respond in a given time period.
The next consideration is IT planning. With a high limit or unlimited mailbox, it is very difficult for an IT department to determine how much storage to allocate to their email servers. If you allocate too little, your servers could max out in a moment’s notice. Allocate too much and you can have storage just sitting around being unused and budget that could have been used elsewhere.
Retention Policy Basics
So, what’s the answer then. Do you limit your end-user’s mailbox? Then what? You still leave the task of mailbox cleanup in the hands of your end users. And, let’s be honest, no one has time for that. Mailboxes will keep being used as a storage system, which will just lead to your help desk getting called even sooner than before because an end user has a mailbox that is full and they need more room to work.
That is where retention policies come into play. Retention policies are part of an email system’s extensive Messaging Record Management (MRM) System. With just a few simply configured retention tags applied to the folders with a mailbox, you can take back control of the mailboxes in your organization. These tags allow you to set how long a message or item stays in mailbox. The tag will then take action on the item, archiving it if your organization still needs it, deleting it if it doesn’t. Easy.
This article is not about the joys and benefits of retention policies. There is a great TechNet article out there that can tell you all about them.
Determining the Right Retention Policy
This post is about getting past an even bigger challenge — making the decision on what type of life span to give the items in your user’s mailbox, especially when it comes to keeping mailbox sizes at a reasonable level, below your mailbox limit. What should you set the retention policies to? Three months, six months, one year, five years? How can you really know unless you run some sort of test to see exactly which time span works the best? Unfortunately, there is no “what if” option on retention policies to see how they would act against a user’s mailbox. This was the exact predicament I was in with one of the big organizations I was working with here at CDW. And what made it even trickier was that my client didn’t want to set the same life span on the entire mailbox. It wanted to set different retention policies per folder.
After doing a little research, my team discovered that this dilemma was easier to get past then we had initially thought. With a little PowerShell magic and the Search-Mailbox command, we got a deeper look inside all users’ mailboxes down to the folder level. The two parameters of the Search-Mailbox command that made it happen were -SearchQuery and -EstimateResultOnly.
The key is to run two separate searches on a user’s mailbox, with the first one searching for all items in a desired folder (saved as a variable).
You can then pipe that variable into a second search that finds everything within a certain time frame. (The Get-Date command comes in handy here to get everything from today back X amount of days.) Using the first search, you are left with what the folder size is now.
Then, using the second search, you have what is left after you set the Retention Policy for X amount of days. Output this to a nice handy CSV file and you have a great report for upper management to show the space you can get back by applying a retention policy for a designated amount of time.
The Wrap Up
I’ll end this blog by saying that it is very important to keep control of your environment in the hands of your admins, not your end users — and not the vendors that supply your messaging solution. Keeping control with the admins will make your environment run better, faster and stronger. Yes, it takes a little legwork getting all the scripts together, however, in the long run things will be much easier.