Shrinking the Transaction Log

SQL Server 2008 R2

 

 

If you know that a transaction log file contains unused space that you will not be needing, you can reclaim the excess space by reducing the size of the transaction log. This process is known as shrinking the log file.
Shrinking can occur only while the database is online and, also, while at least one virtual log file is free. In some cases, shrinking the log may not be possible until after the next log truncation.

Note
Typically, truncation occurs automatically under the simple recovery model when database is backed up and under the full recovery model when the transaction log is backed up. However, truncation can be delayed by a number of factors. For more information, see Factors That Can Delay Log Truncation.

To shrink a log file (without shrinking database files)

• DBCC SHRINKFILE (Transact-SQL)
• How to: Shrink a File (SQL Server Management Studio)

To monitor log-file shrink events

• Log File Auto Shrink Event Class.

To monitor log space

• DBCC SQLPERF (Transact-SQL)
• sys.database_files (Transact-SQL) (See the size, max_size, and growth columns for the log file or files.)

Note

Shrinking database and log files can be set to occur automatically. However, we recommend against automatic shrinking, and the autoshrink database property is set to FALSE by default. If autoshrink is set to TRUE, automatic shrinking reduces the size of a file only when more than 25 percent of its space is unused. The file is shrunk either to the size at which only 25 percent of the file is unused space or to the original size of the file, whichever is larger. For information about changing the setting of the autoshrink property, see How to: View or Change the Properties of a Database (SQL Server Management Studio)—use the Auto Shrink property on the Options page—or ALTER DATABASE SET Options (Transact-SQL)—use the AUTO_SHRINK option.

How Does Shrinking the Log File Work?

Shrinking the transaction log reduces its physical size by removing one or more inactive virtual log files. The unit of the size reduction is always the virtual log file. For example, if you have a 600 megabyte (MB) log file that has been divided into six 100 MB virtual logs, the size of the log file can only be reduced in 100 MB increments. The file size can be reduced to sizes such as 500 MB or 400 MB, but the file cannot be reduced to sizes such as 433 MB or 525 MB. A virtual log file that holds any active log records, that is, an active virtual log file, is part of the logical log, and it cannot be removed. For more information, see Transaction Log Physical Architecture.

Note
The Database Engine chooses the size of the virtual log file dynamically when log files are created or extended. For more information, see Transaction Log Physical Architecture.

For a log file, the current size is the same as the total size of the pages that are used by the virtual log files. Note, however, that pages are not used by the log files. Virtual log files that hold any part of the logical log cannot be freed. If all the virtual log files in a log file hold parts of the logical log, the file cannot be shrunk. Shrinking is not possible until after log truncation marks one or more of the virtual log files as inactive.
A shrink-file operation can remove only inactive virtual log files. If no target size is specified, a shrink-file operation removes only the inactive virtual log files beyond the last active virtual log file in the file. If a target size is specified, a given shrink-file operation removes only enough inactive virtual log files to approach but not exceed the target size. After shrinking, the log file is typically somewhat larger than the target size, and it will never be smaller. The virtual log files make it difficult to predict how much the log file will actually shrink.
When any file is shrunk, the space freed must come from the end of the file. When a transaction log file is shrunk, enough virtual log files from the end of the log file are freed to reduce the log to the size requested by the user. The target_size specified by the user is rounded to the next highest virtual log file boundary. For example, if a user specifies a target_size of 325 MB for our sample 600 MB file that contains six 100 MB virtual log files, the last two virtual log files are removed and the new file size is 400 MB.
A DBCC SHRINKDATABASE or DBCC SHRINKFILE operation immediately tries to shrink the physical log file to the requested size:

• If no part of the logical log in the virtual log files extends beyond the target_size mark, the virtual log files that come after the target_size mark are freed and the successful DBCC statement is completed with no messages.

If part of the logical log in the virtual logs does extend beyond the target_size mark, the SQL Server Database Engine frees as much space as possible and issues an informational message. The message tells you what actions you have to perform to remove the logical log from the virtual logs at the end of the file. After you perform this action, you can then reissue the DBCC statement to free the remaining space.
For example, assume that a 600 MB log file that contains six virtual log files has a logical log that starts in virtual log 3 and ends in virtual log 4 when you run a DBCC SHRINKFILE statement with a target_size of 275 MB, which is three-quarters of the way into virtual log 3:
Virtual log files 5 and 6 are freed immediately, because they do not contain part of the logical log. However, to meet the specified target_size, virtual log file 4 should also be freed, but it cannot because it holds the end portion of the logical log. After freeing virtual log files 5 and 6, the Database Engine fills the remaining part of virtual log file 4 with dummy records. This forces the end of the log file to the end of virtual log file 1. In most systems, all transactions starting in virtual log file 4 will be committed within seconds. This means that the entire active portion of the log is moved to virtual log file 1. The log file now looks similar to this:
The DBCC SHRINKFILE statement also issues an informational message that states that it could not free all the space requested, and that you can run a BACKUP LOG statement to free the remaining space. After the active portion of the log moves to virtual log file 1, a BACKUP LOG statement truncates the entire logical log that is in virtual log file 4:
Because virtual log file 4 no longer holds any portion of the logical log, you can now run the same DBCC SHRINKFILE statement with a target_size of 275 MB. Virtual log file 4 is then freed and the size of the physical log file is reduced to the size you requested.

Note
Certain factors, such as a long-running transaction, can keep virtual log files active for an extended period. This can restrict log shrinkage or even prevent the log from shrinking at all. For more information, see Factors That Can Delay Log Truncation.

SQL SERVER COUNTER - Essential Counters

Essential Counters

While the PAL template for SQL Server is very comprehensive, I also maintain a short list of performance counters that I use for spot checking server performance periodically.  To simplify covering each of the counters, why it’s important and what to look for, we’ll look at counters for CPU, memory, and the disk separately, starting with CPU.

CPU Usage

• Processor
  • %Processor Time
  • %Privileged Time
• Process (sqlservr.exe)
  • %Processor Time
  • %Privileged Time

The Processor\%Processor Time counter is probably the most familiar counter in performance monitor and gives us information about the total CPU usage for the server we are looking at unless it is a virtual machine.  For virtual machines (VMs), the Processor\%Processor Time counter is not a reliable measure of actual CPU usage for the server, and instead shows the percentage of the allocated CPU resources that the VM is actually using at a given point in time.  High values for % Processor  Time in a VM need to be checked against the host performance counters for the VM to determine if the VM is contending for physical CPU allocations with other guest VMs on the same host or not. In addition to the Processor counter we also want to collect the Process (sqlservr.exe)\%Processor Time counter to be able to balance whether a high CPU condition is actually the result of SQL Server utilization or another application that might be running on the server.  For most SQL Server workloads the average processor usage over time should be fairly consistent and unexplained increases from the baseline trending should be investigated further.  Values greater than 80% consistently should also be investigated to determine if the workload is exceeding the current hardware capabilities or for problems that are increasing the overall CPU usage for the instance.

Memory Usage

• Memory
  • Available Mbytes
• SQL Server:Buffer Manager
  • Lazy writes/sec
  • Page life expectancy
  • Page reads/sec
  • Page writes/sec
• SQL Server:Memory Manager
  • Total Server Memory (KB)
  • Target Server Memory (KB)

The first counter that I start with when looking at memory usage on a SQL Server is the Memory\Available MBytes counter.  I start with this counter first to determine if Windows is experiencing memory pressure, which would affect the SQL Server performance counter values potentially.  The Memory\Available MBytes counter should ideally be above 150-300MB for the server, which leaves memory available for other applications to run without pushing Windows into a low memory condition.  When the Available MBytes counter drops below 64MB, on most servers Windows signals a low memory notification that SQL Server monitors for, and the SQLOS ( the ‘operating system’) inside of SQL Server will reduce memory usage as a result of this notification occurring.
After confirming that Windows has available memory to prevent SQL Server from shrinking memory usage, the next counters I generally look at are Buffer Manager\Page life expectancy and Lazy writes/sec.  The Page life expectancy (PLE) should be generally consistent on average, but may fluctuate with changes in the server workload, with lower values at peak periods.  In general, the more memory allocated to a SQL Server instance, the higher I’d like to see this counter’s normal value.  For example, a server with 230GB RAM allocated to the SQL Server buffer pool and a PLE of 300 would equate roughly to 785MB/sec of I/O activity to maintain the page churn inside of the buffer pool.  While it might be possible for the I/O subsystem to keep up with this demand, this represents a significant amount of page churn in the buffer pool and may be a sign of missing indexes, implicit conversions due to mismatched data types, and all kinds of other problems that can be fixed if identified as the root cause.
If you find a low PLE for the server, look at the other performance counters in the Buffer Manager category for correlation of overall memory pressure inside of SQL Server.  If Lazy writes/sec is consistently experiencing non-zero values with a low PLE and elevated values for Page reads/sec and Page writes/sec the server is experiencing buffer pool contention and you will need to go about troubleshooting this problem further.  If the Memory\Available MBytes counter was fluctuating and under the 64MB low memory threshold, looking at the Memory Manager\Total Server Memory (KB) and Target Server Memory (KB) counters will tell you if that has resulted in SQL Server reducing the size of the buffer pool in response.  On a stable system Total Server Memory (KB) will be lower than Target Server Memory (KB) during the initial buffer pool ramp up, but then remain equal under normal operation unless a low memory condition occurs.  If the server is a VM running on VMware, look for memory ballooning by the host with the VM Memory\Memory Ballooned (MB) counter for non-zero values to see if the host is causing the low memory condition.

Disk Usage

• Physical Disk
  • Avg. Disk sec/Read
  • Avg. Disk Bytes/Read
  • Avg. Disk sec/Write
  • Avg. Disk Bytes/Write
• Paging File
  • %Usage
• SQL Server:Access Methods
  • Forwarded Records/sec
  • Full Scans/sec
  • Index Searches/sec

The Avg. Disk sec/Read and /Write counters provide the current average latency for each of the disks on the server.  Latency is one of the most important metrics for SQL Server I/O performance, but the latency should be compared to the size of I/Os that are being performed before determining whether or not a specific value is an indicator of a problem or not.  As the size of the I/O operations increases, so does the latency for the operation, so it would be normal to see higher latency values for a reporting workload doing large table scans vs. a transactional workload with smaller I/O operations occurring.  The Microsoft general recommendations for I/O latency for SQL Server are:

• < 8ms: excellent
• < 12ms: good
• < 20ms: fair
• > 20ms: poor

Over the last two years consulting, only a few of the servers that I’ve looked at during health checks meet the <20ms latency numbers for data and log files.  Most servers tend to fall into the < 30ms range for I/O latency per disk on average.  SSDs are changing this rapidly, and we’re seeing more and more disk configurations that include SSDs and the result is very low I/O latency.  When looking at our overall I/O for the server, reviewing the Access Method counters for Full Scans/sec, Forwarded Records/sec, and Index Searches/sec can give us a clue to the type of workload that is occurring to generate the I/O.

Summary

An important consideration when looking at performance counters, or any monitoring data from SQL Server for that matter, is that no single data point will tell you the root cause of a problem, if one occurs. For performance counters, you need to look across multiple counters for correlating information to pinpoint the root of problems.
For example, if we look at disk I/O and see high latency numbers with lower I/O sizes on average, we could infer that we have a disk bottleneck and we need to improve our I/O performance. However, if we look at the Buffer Manager\Page life expectancy and find that it is lower than our normal baseline numbers for the server, and then see the Buffer Manager\Page Reads/sec is higher than usual, the data would point to a memory contention in the buffer pool which is going to affect I/O performance to keep up with the page churn occurring in the buffer pool.
Understanding the counters and how they relate makes it much easier to spot when problems are occurring and then pinpoint where the actual root of the problem might be.

Top 10 SQL Server Counters for Monitoring SQL Server Performance

By Gregory A. Larsen
Do you have a list of SQL Server Counters you review when monitoring your SQL Server environment? Counters allow you a method to measure current performance, as well as performance over time. Identifying the metrics you like to use to measure SQL Server performance and collecting them over time gives you a quick and easy way to identify SQL Server problems, as well as graph your performance trend over time.
Below is my top 10 list of SQL Server counters in no particular order. For each counter I have described what it is, and in some cases I have described the ideal value of these counters. This list should give you a starting point for developing the metrics you want to use to measure database performance in your SQL Server environment.

1. SQLServer: Buffer Manager: Buffer cache hit ratio

The buffer cache hit ratio counter represents how often SQL Server is able to find data pages in its buffer cache when a query needs a data page. The higher this number the better, because it means SQL Server was able to get data for queries out of memory instead of reading from disk. You want this number to be as close to 100 as possible. Having this counter at 100 means that 100% of the time SQL Server has found the needed data pages in memory. A low buffer cache hit ratio could indicate a memory problem.

2. SQLServer: Buffer Manager: Page life expectancy

The page life expectancy counter measures how long pages stay in the buffer cache in seconds. The longer a page stays in memory, the more likely SQL Server will not need to read from disk to resolve a query. You should watch this counter over time to determine a baseline for what is normal in your database environment. Some say anything below 300 (or 5 minutes) means you might need additional memory.

3. SQLServer: SQL Statistics: Batch Requests/Sec

Batch Requests/Sec measures the number of batches SQL Server is receiving per second. This counter is a good indicator of how much activity is being processed by your SQL Server box. The higher the number, the more queries are being executed on your box. Like many counters, there is no single number that can be used universally to indicate your machine is too busy. Today’s machines are getting more and more powerful all the time and therefore can process more batch requests per second. You should review this counter over time to determine a baseline number for your environment.

4. SQLServer: SQL Statistics: SQL Compilations/Sec

The SQL Compilations/Sec measure the number of times SQL Server compiles an execution plan per second. Compiling an execution plan is a resource-intensive operation. Compilations/Sec should be compared with the number of Batch Requests/Sec to get an indication of whether or not complications might be hurting your performance. To do that, divide the number of batch requests by the number of compiles per second to give you a ratio of the number of batches executed per compile. Ideally you want to have one compile per every 10 batch requests.

5. SQLServer: SQL Statistics: SQL Re-Compilations/Sec

When the execution plan is invalidated due to some significant event, SQL Server will re-compile it. The Re-compilations/Sec counter measures the number of time a re-compile event was triggered per second. Re-compiles, like compiles, are expensive operations so you want to minimize the number of re-compiles. Ideally you want to keep this counter less than 10% of the number of Compilations/Sec.

6. SQLServer: General Statistics: User Connections

The user connections counter identifies the number of different users that are connected to SQL Server at the time the sample was taken. You need to watch this counter over time to understand your baseline user connection numbers. Once you have some idea of your high and low water marks during normal usage of your system, you can then look for times when this counter exceeds the high and low marks. If the value of this counter goes down and the load on the system is the same, then you might have a bottleneck that is not allowing your server to handle the normal load. Keep in mind though that this counter value might go down just because less people are using your SQL Server instance.

7. SQLServer: Locks: Lock Waits / Sec: _Total

In order for SQL Server to manage concurrent users on the system, SQL Server needs to lock resources from time to time. The lock waits per second counter tracks the number of times per second that SQL Server is not able to retain a lock right away for a resource. Ideally you don't want any request to wait for a lock. Therefore you want to keep this counter at zero, or close to zero at all times.

8. SQLServer: Access Methods: Page Splits / Sec

This counter measures the number of times SQL Server had to split a page when updating or inserting data per second. Page splits are expensive, and cause your table to perform more poorly due to fragmentation. Therefore, the fewer page splits you have the better your system will perform. Ideally this counter should be less than 20% of the batch requests per second.

9. SQLServer: General Statistic: Processes Block

The processes blocked counter identifies the number of blocked processes. When one process is blocking another process, the blocked process cannot move forward with its execution plan until the resource that is causing it to wait is freed up. Ideally you don't want to see any blocked processes. When processes are being blocked you should investigate.

10. SQLServer: Buffer Manager: Checkpoint Pages / Sec

The checkpoint pages per second counter measures the number of pages written to disk by a checkpoint operation. You should watch this counter over time to establish a baseline for your systems. Once a baseline value has been established you can watch this value to see if it is climbing. If this counter is climbing, it might mean you are running into memory pressures that are causing dirty pages to be flushed to disk more frequently than normal.

Exchange Server Role Requirements Calculator Update

v7.8 of the calculator introduces support for Exchange 2016! Yes, that’s right, you don’t need a separate calculator, v7.8 and later supports Exchange 2013 or Exchange 2016 deployments. Moving forward, the calculator is branded as the Exchange Server Role Requirements Calculator.
When you open the calculator you will find a new drop-down option in the Input tab that allows you to select the deployment version. Simply choose 2013 or 2016:

When you choose 2016, you will notice the Server Multi-Role Configuration option is disabled due to the fact that Exchange 2016 no longer provides the Client Access Server role.
As discussed in the Exchange 2016 Architecture and Preferred Architecture articles, the volume format best practice recommendation for Exchange data volumes has changed in Exchange 2016 as we now recommend ReFS (with the integrity feature disabled). By default, for Exchange 2016 deployments, the calculator scripts will default to ReFS (Exchange 2013 deployments will default to NTFS). This is exposed in the Export Mount Points File dialog:

The DiskPart.ps1 and CreateDag.ps1 scripts have been updated to support formatting the volume as ReFS (and disabling the integrity feature at the volume level) and enabling AutoReseed support for ReFS.
This release also improves the inputs of all dialogs for the distribution scripts by persisting values across the various dialogs (e.g., global catalog values).
For all the other improvements and bug fixes, please review the Release Notes, or download the update directly.
As always we welcome feedback and please report any issues you may encounter while using the calculator by emailing strgcalc AT microsoft DOT com.
Ross Smith IV

Namespace Planning in Exchange 2016

If you are like the vast majority of our customers, you already have some version(s) of Exchange deployed in your environment. Depending on the version, you may have different namespace requirements today.

Exchange 2010

Exchange 2010 leverages the Autodiscover service for enabling client profile changes, so that namespace exists.
Exchange 2010 introduced additional namespace requirements, which resulted in additional complexity around namespace planning, especially for site resilient solutions:

1. Primary datacenter Internet protocol namespace (mail.contoso.com)
2. Secondary datacenter Internet protocol namespace (mail2.contoso.com)
3. Primary datacenter Outlook Web App failback namespace (mailpri.contoso.com)
4. Secondary datacenter Outlook Web App failback namespace (mailsec.contoso.com)
5. Transport namespace (smtp.contoso.com)
6. Primary datacenter RPC Client Access namespace (rpc.contoso.com)
7. Secondary datacenter RPC Client Access namespace (rpc2.contoso.com)

Out of these seven namespaces, five of them were required on certificates. The RPC Client Access namespaces were not required on the certificate because they were accessed via RPC connectivity and not via an Internet-based protocol, like HTTP.

Exchange 2016

One of the benefits of the Exchange 2016 architecture (first introduced in Exchange 2013) is that the namespace model can be simplified, when compared to Exchange 2010.
An example of how it can be simplified can be seen when thinking about a site resilience scenario. If you have two datacenters participating in a site resilient architecture, by replacing the Exchange 2010 infrastructure with Exchange 2016, five namespaces could potentially be removed:

1. Secondary datacenter Internet protocol namespace (mail2.contoso.com)
2. Primary datacenter Outlook Web App failback namespace (mailpri.contoso.com)
3. Secondary datacenter Outlook Web App failback namespace (mailsec.contoso.com)
4. Primary datacenter RPC Client Access namespace (rpc.contoso.com)
5. Secondary datacenter RPC Client Access namespace (rpc2.contoso.com)

There’s two reasons for this.
First, Exchange 2016 no longer leverages an RPC Client Access namespace.This is due to the architectural changes within the product - for a given mailbox, the protocol that services the request is always going to be the protocol instance on the Mailbox server that hosts the active copy of the database for the user’s mailbox. In other words, the RPC Client Access service is no longer decoupled from the store, like it was in Exchange 2010.
Second, as mentioned, the Client Access services proxies requests to the Mailbox server hosting the active database copy.

Figure 1: Client Access services (on MBX Server 1) proxying traffic to the Mailbox server hosting the active database copy (on MBX Server 3)
This proxy logic is not limited to the Active Directory site boundary. Unlike Exchange 2010, Exchange 2016 does not require the client namespaces to move with the DAG during an activation event – a Mailbox server in one Active Directory site can proxy a session to a Mailbox server that is located in another Active Directory site. This means that unique namespaces are no longer required for each datacenter (mail.contoso.com and mail2.contoso.com); instead, only a single namespace is needed for the datacenter pair – mail.contoso.com. This also means failback namespaces are also not required during DAG activation scenarios, so mailpri.contoso.com and mailsec.contoso.com are removed.

Namespace Models

Depending on your architecture and infrastructure you have two choices:

1. Deploy a unified namespace for the site resilient datacenter pair (unbound model).
2. Deploy a dedicated namespace for each datacenter in the site resilient pair (bound model).

It’s also worth mentioning that these choices are also tied to the DAG architecture.

Unbound Model

In an unbound model, you have a single DAG deployed across the datacenter pair. This DAG has Mailbox servers in each datacenter – typically all Mailbox servers are active and host active database copies, however you could deploy all active copies in a single datacenter. Mailboxes for both datacenters are dispersed across the mailbox databases within this DAG. In this model, clients can connect to both datacenters in the event there is a WAN failure – neither datacenter’s connectivity is a boundary, hence the term unbound. It does not guarantee, however, the connectivity provides users an equal experience; meaning one connection may provide a better user experience because it has lower latency or more bandwidth.
In an unbound model, a single namespace is preferred because either datacenter can service the user request. This means that from a load balancing perspective, the Exchange 2016 Mailbox servers in both datacenters participate in handling traffic, as seen in the following diagram, where VIP (virtual IP address) is the load balanced IP address associated with the namespace:

Figure 2: Single Namespace used across Site Resilient Datacenter Pair (Unbound Model)
As a result, for a given datacenter, the expectation is that 50% of the traffic will be proxied from the other datacenter.

Bound Model

As its name implies, in a bound model, users are associated (or bound) to a specific datacenter. In other words, there is preference to have the users operate out of one datacenter during normal operations and only have the users operate out of the second datacenter during failure events. There is also a possibility that users do not have equal connectivity to both datacenters. Typically, in a bound model, there are two DAGs deployed in the datacenter pair. Each DAG contains a set of mailbox databases for a particular datacenter; by controlling where the databases are mounted, you control connectivity.
In a bound model, multiple namespaces are preferred, two per datacenter (primary and failback namespaces), to prevent clients trying to connect to the datacenter where they may have no connectivity. Switchover to the other datacenter is a controlled event.

Figure 3: Multiple Namespaces used across Site Resilient Datacenter Pair (Bound Model)

Autodiscover Namespace

Exchange 2016 takes advantage of the Autodiscover service for client profile configuration; so the autodiscover.contoso.com namespace remains in place.

Office Online Server Namespaces

The document collaboration features included in Outlook on the web require Office Online Server. In site resilient deployments, you want to deploy an Office Online Server farm in each datacenter that participates in the site resilient datacenter pair.This ensures that there is a local instance that can service the document collaboration requests for the local mailboxes and avoids cross-site proxy scenarios.
From a namespace perspective, this means that each datacenter in the site resilient datacenter pair requires a unique namespace for Office Online Server; in other words, the namespace model for Office Online Server is a bound model.The namespace model that is used by Office Online Server is mutually exclusive from the model used by Exchange, meaning that you can deploy Exchange using an unbound model, while utilizing a bound model for Office Online Server as seen in the following figure:
 
Figure 4: Office Online Server Namespaces (Bound Model) with an Exchange Unbound Model Namespace
As all the data serviced by Office Online Server is either stored in Exchange or SharePoint, during a datacenter outage, namespace manipulation steps are not required. For example, if we refer to the previous diagram – if the West datacenter fails, you don’t need to change the DNS record for the Office Online Server namespace in West and point it to the load balancer in East. This is due to the architecture of Exchange and Office Online Server. Any Exchange 2016 Mailbox server will always proxy the client’s request to the Mailbox server that hosts the user’s mailbox database. The Mailbox server hosting the user’s mailbox is responsible for generating the Office Online Server URL that is used by OWA. This URL is defined per-Mailbox server, thereby ensuring that any Office Online Server interactions are always local to the Mailbox server.

Internal vs. External Namespaces

Since the release of Exchange 2007, the recommendation is to deploy a split-brain DNS infrastructure for the Internet-based client namespaces.A split-brain DNS infrastructure enables different IP addresses to be returned for a given namespace based on where the client resides – if the client is within the internal network, the IP address of the internal load balancer is returned; if the client is external, the IP address of the external gateway/firewall is returned.
This approach simplifies the end-user experience – users only have to know a single namespace (e.g., mail.contoso.com) to access their data, regardless of where they are connecting. A split-brain DNS infrastructure, also simplifies the configuration of the Exchange virtual directories, as the InternalURL and ExternalURL values within the environment can be the same value.
In the event that you do not deploy a split-brain DNS (also known as split-DNS) infrastructure, Exchange 2016 does allow you to specify different namespaces for internal clients vs. external clients for all clients.

Important: In the event that you are utilizing a split-brain DNS infrastructure, then you must utilize the same authentication value for both your internal and external Outlook Anywhere settings, or switch to use different names for Outlook Anywhere inside and out. Outlook gives priority to the internal settings over the external settings and since the same namespace is used for both, regardless of whether the client is internal or external, it will utilize only the internal authentication settings.

Regional Namespace

The concept of regional namespaces has existed since OWA debuted in 1997. A regional namespace is a way for clients to connect to the client access endpoint that is closest to the Mailbox servers hosting the data.
Use of a regional namespace does not necessarily mean you are restricted to a bound model, either. This is because depending on your infrastructure and network capabilities, you may choose to have a dedicated namespace for each datacenter pair. For example, your company may have a set of datacenters in North America and in Europe, and due to a desire to reduce cross-region network traffic, you deploy a dedicated namespace for each region (notice that within a region, the unbound model is used):

Figure 5: : Regional Namespaces coupled with Geo-DNS to Round-Robin between Datacenters within a Region

Namespaces and Active Directory Site Topologies

When planning your namespace architecture, it is important to understand that namespaces and authentication settings must be identical and/or consistent within an Active Directory site. For example, when Autodiscover generates a response to send to the client, it generates a list of internal URLs based on the virtual directory settings of the Mailbox servers located in the Active Directory where the mailbox is located. If you attempt to have multiple namespaces within a single Active Directory site, clients will be randomly directed to different namespaces. Likewise, setting different authentication settings within an Active Directory site will lead to different behaviors for the clients. In other words, you can only define different namespace and authentication settings between Active Directory sites, not within Active Directory sites.

Conclusion

Exchange 2016 introduces significant flexibility in your namespace architecture, enabling deployment of a single unified namespace for a site resilient datacenter pair (or worldwide), or deployment of multiple namespaces.  As we delve into the intricacies surrounding load balancing principles and client connectivity, you will understand (hopefully) how to choose the best namespace model.
FONTE Ross Smith IV

Exchange 2016 Coexistence with Kerberos Authentication

• 1

With the release of Exchange Server 2016, I thought it would be best to document our guidance around utilizing Kerberos authentication for MAPI clients. Like with the last two releases, the solution leverages deploying an Alternate Service Account (ASA) credential so that domain-joined and domain-connected Outlook clients, as well as other MAPI clients, can utilize Kerberos authentication.
Depending on your environment, you may utilize a single ASA or have multiple ASA accounts during the coexistence period.

Exchange 2016 Coexistence with Exchange 2010

Two ASA credentials will be utilized in this environment. One ASA credential will be assigned to Exchange 2010 and host the exchangeMDB, ExchangeRFR, and ExchangeAB SPNs, while a second ASA credential will be assigned to Exchange 2016 and host the http SPN records.
For more information, see the Exchange 2013 and Exchange 2010 Coexistence with Kerberos Authentication article.

Exchange 2016 Coexistence with Exchange 2013

A single ASA credential will be utilized and configured on all Exchange 2013 and Exchange 2016 servers.
For more information, see the Exchange 2013 Configuring Kerberos authentication for load-balanced Client Access servers article.

Note: The RollAlternateserviceAccountCredential.ps1 script included in Exchange 2016 scripts directory utilizes the new cmdlets, Get/Set-ClientAccessService. This cmdlet will not execute correctly on Exchange 2013 servers. Use the RollAlternateserviceAccountCredential.ps1 script included in Exchange 2013 scripts directory to deploy the ASA across Exchange servers.

Exchange 2016 Coexistence with both Exchange 2010 and Exchange 2013

Two ASA credentials will be utilized in this environment. One ASA credential will be assigned to Exchange 2010 and host the exchangeMDB, ExchangeRFR, and ExchangeAB SPNs, while a second ASA credential will be assigned to the Exchange 2013 and Exchange 2016 servers to host the http SPN records.
For more information, see the Exchange 2013 and Exchange 2010 Coexistence with Kerberos Authentication article.
Ross Smith IVd


Fonte: Ross Smith IV

Windows 10 Upgrade ERRO 80240020

ERRO 80240020 RESOLVIDO!

Pra quem tiver baixado os arquivos pelo Windows Update e no momento da instalação aparece o erro 80240020, faça o seguinte:

1º - O erro não está relacionado com arquivos corrompidos;
2º - No campo "pesquisa" ou no "executar" digite: "regedit" (sem aspas);
3º - Irá abir o Editor de Registro;
4º - Localize a chave do Registro: [ HKEY_LOCAL_MACHINE \ SOFTWARE \ Microsoft \ Windows \ CurrentVersion \ WindowsUpdate \ OSUpgrade ];
5º - Esse caminho já deve existir em sua máquina (caso contrário crie as pastas);
6º - Crie um novo Valor DWORD (32 bits) com o seguinte nome: "AllowOSUpgrade" (sem aspas);
7º - Marque a opção "Hexadecimal" e digite o valor: "1" (sem aspas);
8º - Deverá aparecer o seguinte valor no novo registro criado: 0x00000001;
9º - Feche o Editor de Registro e abra o Windows Update (deixe a janela aberta);
10º - Abra o prompt de comando (digite cmd no campo pesquisar ou executar) como Administrador;
11º - Cole no prompt de comando o seguinte: wuauclt.exe / UpdateNow (não tecle Enter ainda);
12º - Na tela do Windows Update clique em "Procurar atualizações";
13º - Nesse momento volte para o prompt de comando e tecle Enter;
14º - Feito isso, o Windows Update poderá baixar alguns arquivos e irá abrir a tela para iniciar a instalação da atualização para o Windows 10.

Como forçar o download e a instalação do Windows 10 no seu computador

O Windows 10 foi lançado oficialmente nesta quarta-feira (29). Mas, conforme avisou a Microsoft, nem todo mundo está na dianteira da fila para atualização. Se esse for o seu caso, veja como forçar o download do novo sistema no seu PC, desde que você tenha realizado uma pré-reserva e, é claro, esteja usando Windows 7, 8 ou 8.1 originais. Confira o passo a passo para instalação o Windows 10.
Ele chegou! Saiba o que esperar do lançamento do Windows 10 nos PCs

'Entre pela janela', 'fure fila' e instale o Windows 10 antes de todo mundo (Foto: Reprodução/Microsoft)

ATENÇÃO: Antes de prosseguir, é importante fazer um backup de todos os seus arquivos em uma mídia externa. Assim, você está a salvo caso haja qualquer imprevisto no meio do caminho – afinal, após forçar o download, a instalação do Windows 10 começa imediatamente e é inviável interrompê-la.
Passo 1. Abra o Windows Explorer e navegue até a pasta C:/Windows/SoftwareDistribution/Download;

Acesse a pasta de downloads do Windows Update (Foto: Reprodução/Paulo Alves)

Passo 2. Selecione todos os arquivos contidos ali e apague-os da máquina. Se você vir uma mensagem pedindo permissão do administrador, clique em “Continuar” e insira sua senha;

Apague todos os itens da pasta (Foto: Reprodução/Paulo Alves)

Passo 3. Abra o menu Iniciar e abra o Windows Update;

Acesse o Windows Update (Foto: Reprodução/Paulo Alves)

Passo 4. De novo no menu Iniciar, dessa vez acesse o Prompt de Comando do Windows procurando por “cmd”;

Abra o Prompt de Comando (Foto: Reprodução/Paulo Alves)

Passo 5. No Prompt, digite o comando “wuauclt.exe /updatenow” (sem as aspas). Cuidado, nesse momento você deve somente digitar SEM pressionar Enter;

Digite o comando ainda sem dar Enter (Foto: Reprodução/Paulo Alves)

Passo 6. Vá até o Windows Update e clique no botão “Procurar Atualizações”. Rapidamente, volte ao Prompt e dê um Enter para inserir o comando;

Busque por atualizações do Windows e insira o comando do prompt (Foto: Reprodução/Paulo Alves)

Passo 7. No Windows Update, você verá uma mensagem informando que o Windows 10 está sendo baixado.

Verifique o download do Windows 10 (Foto: Reprodução/Paulo Alves)

Pronto. Agora basta esperar pelo download dos pacotes de instalação e desfrutar do novo sistema em seguida. Tenha em conta que, em alguns casos, é necessário reiniciar o computador e procurar novamente por atualizações no Windows Update para que o download do Windows 10 seja efetuado.
Lembre ainda que, durante as primeiras horas em que o software “está no ar”, os servidores da Microsoft podem ficar superlotados com pedidos do mundo inteiro. Então, é importante ter paciência para obter o update sem bugs. Em alguns casos, o download demora vários minutos para sair de 0%.

Fonte: TechTudo

Memory Object

The Memory performance object consists of counters that describe the behavior of physical and virtual memory on the computer. Physical memory is the amount of random-access memory (RAM) on the computer. Virtual memory consists of space in physical memory and on disk. Many of the memory counters monitor paging, which is the movement of pages of code and data between disk and physical memory. Excessive paging, a symptom of a memory shortage, can cause delays which interfere with all system processes.

Counter Name	Description	Counter Type
% Committed Bytes In Use	shows the ratio of Memory\ Committed Bytes to the Memory\ Commit Limit. Committed memory is physical memory in use for which space has been reserved in the paging file so that it can be written to disk. The commit limit is determined by the size of the paging file. If the paging file is enlarged, the commit limit increases, and the ratio is reduced.	PERF_RAW_FRACTION
Available Bytes	Shows the amount of physical memory, in bytes, available to processes running on the computer. It is calculated by summing adding the amount of space on the zeroed, free, and standby memory lists. Free memory is ready for use; zeroed memory consists of pages of memory filled with zeros to prevent later processes from seeing data used by a previous process; standby memory is memory that has been removed from a process's working set (its physical memory) en route to disk but is still available to be recalled.	PERF_COUNTER_RAWCOUNT
Available KBytes	Shows the amount of memory available to processes running on the computer, in kilobytes rather than bytes, as reported by Memory\Available Bytes.	PERF_COUNTER_RAWCOUNT
Available MBytes	Shows the amount of memory available to processes running on the computer, in megabytes rather than bytes, as reported by Memory\Available Bytes.	PERF_COUNTER_RAWCOUNT
Cache Bytes	Shows the sum of the values of System Cache Resident Bytes, System Driver Resident Bytes, System Code Resident Bytes, and Pool Paged Resident Bytes.	PERF_COUNTER_RAWCOUNT
Cache Bytes Peak	Shows the maximum number of bytes used by the file system cache since the system was last restarted. This might be larger than the current size of the cache.	PERF_COUNTER_RAWCOUNT
Cache Faults/sec	hows the rate at which faults occur when a page sought in the file system cache is not found and must be retrieved from elsewhere in memory (a soft fault) or from disk (a hard fault). This counter shows the number of faults, without regard for the number of pages faulted in each operation.	PERF_COUNTER_COUNTER
Commit Limit	Shows the amount of virtual memory, in bytes, that can be committed without having to extend the paging file(s). Committed memory is physical memory which has space reserved on the disk paging files. There can be one or more paging files on each physical drive. If the paging file(s) are expanded, this limit increases accordingly.	PERF_COUNTER_RAWCOUNT
Committed Bytes	Shows the amount of committed virtual memory, in bytes.	PERF_COUNTER_RAWCOUNT
Demand Zero Faults/sec	Shows the rate at which a zeroed page is required to satisfy the fault. Zeroed pages, pages emptied of previously stored data and filled with zeros, are security features in Windows 2000 that prevent processes from seeing data stored by earlier processes that used the memory space. Windows 2000 maintains a list of zeroed pages to accelerate this process. This counter shows numbers of faults, without regard to the numbers of pages retrieved to satisfy the fault.	PERF_COUNTER_COUNTER
Free System Page Table Entries	Shows the number of page table entries not currently in use by the system.	PERF_COUNTER_RAWCOUNT
Page Faults/sec	Shows the average number of pages faulted per second. It is measured in numbers of pages faulted; because only one page is faulted in each fault operation, this is also equal to the number of page fault operations. This counter includes both hard faults (those that require disk access) and soft faults (where the faulted page is found elsewhere in physical memory). Most processors can handle large numbers of soft faults without significant consequence. However, hard faults, which require disk access, can cause delays.	PERF_COUNTER_COUNTER
Page Reads/sec	Shows the rate at which the disk is read to resolve hard page faults. It shows numbers of read operations, without regard to the number of pages retrieved in each operation. Hard page faults occur when a process references a page in virtual memory that is not in its working set or elsewhere in physical memory, and must be retrieved from disk. This counter is a primary indicator of the kinds of faults that cause system-wide delays. It includes read operations to satisfy faults in the file system cache (usually requested by applications) and in noncached mapped memory files. Compare the value of Page Reads/sec to the value of Pages Input/sec to find an average of how many pages were read during each read operation.	PERF_COUNTER_COUNTER
Page Writes/sec	Shows the rate at which pages are written to disk to free up space in physical memory. Pages are written to disk only if they are changed while in physical memory, so they are likely to hold data, not code. This counter shows write operations, without regard to the number of pages written in each operation.	PERF_COUNTER_COUNTER
Pages Input/sec	Shows the rate at which pages are read from disk to resolve hard page faults. Hard page faults occur when a process refers to a page in virtual memory that is not in its working set or elsewhere in physical memory, and must be retrieved from disk. When a page is faulted, the system tries to read multiple contiguous pages into memory to maximize the benefit of the read operation. Compare Pages Input/sec to Page Reads/sec to find the average number of pages read into memory during each read operation	PERF_COUNTER_COUNTER
Pages Output/sec	Shows the rate at which pages are written to disk to free up space in physical memory. A high rate of pages output might indicate a memory shortage. Windows 2000 writes more pages back to disk to free up space when physical memory is in short supply. This counter shows numbers of pages, and can be compared to other counts of pages without conversion.	PERF_COUNTER_COUNTER
Pages/sec	Shows the rate at which pages are read from or written to disk to resolve hard page faults. This counter is a primary indicator of the kinds of faults that cause system-wide delays. It is the sum of Memory\ Pages Input/sec and Memory\ Pages Output/sec. It is counted in numbers of pages, so it can be compared to other counts of pages, such as Memory\ Page Faults/sec, without conversion. It includes pages retrieved to satisfy faults in the file system cache (usually requested by applications) and noncached mapped memory files.	PERF_COUNTER_COUNTER
Pool Nonpaged Allocs	Shows the number of calls to allocate space in the nonpaged pool. It is measured in numbers of calls to allocate space, regardless of the amount of space allocated in each call.	PERF_COUNTER_RAWCOUNT
Pool Nonpaged Bytes	Shows the size, in bytes, of the nonpaged pool. Memory\ Pool Nonpaged Bytes is calculated differently than Process\ Pool Nonpaged Bytes, so it might not equal Process(_Total )\ Pool Nonpaged Bytes.	PERF_COUNTER_RAWCOUNT
Pool Paged Allocs	Shows the number of calls to allocate space in the paged pool. It is measured in numbers of calls to allocate space, regardless of the amount of space allocated in each call.	PERF_COUNTER_RAWCOUNT
Pool Paged Bytes	Shows the size, in bytes, of the paged pool. Memory\ Pool Paged Bytes is calculated differently than Process\ Pool Paged Bytes, so it might not equal Process(_Total )\ Pool Paged Bytes.	PERF_COUNTER_RAWCOUNT
Pool Paged Resident Bytes	Shows the current size, in bytes, of the paged pool. Space used by the paged and nonpaged pools is taken from physical memory, so a pool that is too large denies memory space to processes.	PERF_COUNTER_RAWCOUNT
System Cache Resident Bytes	Shows the size, in bytes, of pageable operating system code in the file system cache. This value includes only current physical pages and does not include any virtual memory pages not currently resident. It does not equal the System Cache value shown in Task Manager. As a result, this value may be smaller than the actual amount of virtual memory in use by the file system cache. This value is a component of Memory\ System Code Resident Bytes which represents all pageable operating system code that is currently in physical memory.	PERF_COUNTER_RAWCOUNT
System Code Resident Bytes	Shows the size, in bytes, of operating system code currently in physical memory that can be written to disk when not in use. This value is a component of Memory\ System Code Total Bytes, which also includes operating system code on disk. Memory\ System Code Resident Bytes (and Memory\ System Code Total Bytes) does not include code that must remain in physical memory and cannot be written to disk.	PERF_COUNTER_RAWCOUNT
System Code Total Bytes	Shows the size, in bytes, of pageable operating system code currently in virtual memory. It is a measure of the amount of physical memory being used by the operating system that can be written to disk when not in use. This value is calculated by adding the bytes in Ntoskrnl.exe, Hal.dll, the boot drivers, and file systems loaded by Ntldr/osloader. This counter does not include code that must remain in physical memory and cannot be written to disk.	PERF_COUNTER_RAWCOUNT
System Driver Resident Bytes	Shows the size, in bytes, of pageable physical memory being used by device drivers. It is the working set (physical memory area) of the drivers. This value is a component of Memory\ System Driver Total Bytes, which also includes driver memory that has been written to disk. Neither Memory\ System Driver Resident Bytes nor Memory\ System Driver Total Bytes includes memory that cannot be written to disk.	PERF_COUNTER_RAWCOUNT
System Driver Total Bytes	Shows the size, in bytes, of pageable virtual memory currently being used by device drivers. Pageable memory can be written to disk when it is not being used. It includes physical memory (Memory\ System Driver Resident Bytes) and code and data written to disk. It is a component of Memory\ System Code Total Bytes.	PERF_COUNTER_RAWCOUNT
Transition Faults/sec	Shows the rate at which page faults are resolved by recovering pages that were being used by another process sharing the page, or were on the modified page list or the standby list, or were being written to disk at the time of the page fault. The pages were recovered without additional disk activity. Transition faults are counted in numbers of faults; because only one page is faulted in each operation, it is also equal to the number of pages faulted.	PERF_COUNTER_COUNTER
Write Copies/sec	Shows the rate at which page faults are caused by attempts to write that have been satisfied by copying the page from elsewhere in physical memory. This is an economical way of sharing data since pages are only copied when they are written to; otherwise, the page is shared. This counter shows the number of copies, without regard to the number of pages copied in each operation.	PERF_COUNTER_COUNTER

Monitor SQL Server using Performance Monitor on Windows Server 2008 R2

Skip to end of metadata

• Attachments:7
• Added by SSI KB Admin, last edited by SSI KB Admin on Feb 27, 2012  (view change)

Go to start of metadata

Table of Contents

1. Open Performance Monitor (AKA perfmon)
2. Setup the Data Collector Set
3. Start the Data Collector Set
4. Stop the Data Collector Set
5. HOWTO: Change the User for the Data Collector Set
6. HOWTO: Change the Log file Location
7. HOWTO: Create a Data Collector Set Template
8. HOWTO: Use a Custom Template to Create a Data Collector Set

Step 1: Open Performance Monitor (AKA perfmon)

1. Press the Start + R keys to get the Run dialog.
2. Type “perfmon”:
    
3. Click the “OK” button.

Step 2: Setup the Data Collector Set

1. Left click the arrow found to the left of "Data Collector Sets" to expand the tree:
   
2. Right click "User Defined", and select "New > Data Collector Set".
3. Specify a unique name for the Data Collector Set:
   
4. Select the "Create manually (Advanced)" radio button.
5. Click the "Next" button.
6. Check off "Performance counter", found under the "Create data logs":
    
7. Click the "Next" button.
8. Click the "Add" button.
9. OPTIONAL: If using Performance Monitor to watch a remote host.
   1. Type the hostname into the “Select counters from computer” text field:
       
   2. Press the Tab key to trigger the dialog to query the remote host specified for available counters, and refresh the list of counters (can take a couple of minutes).
10. Scroll to "MSSQL$[appropriate instance name]: General Statistics".
11. Click the "+" to expand the node (found to the right of "MSSQL$[appropriate instance name]: General Statistics)
     
12. Select "User Connections".
13. Click the "Add" button.
14. Scroll to "MSSQL$[appropriate instance name]: Locking".
15. Click the "+" to expand the node (found to the right of "MSSQL$[appropriate instance name]: Locking)
     
16. Select "Average Wait Time (ms)".
17. Select "Database" for "Instances of selected object".
18. Click the "Add" button.
19. Click the "OK" button.
20. OPTIONAL: Change the log location.
21. Click the "Next" button.
22. OPTIONAL: Change the user account this Data Collector Set will use for credentials.
23. Click the "Finish" button.

Step 3: Start the Data Collector Set

1. Right click on the Data Collector Set created in Step 2.
2. Select "Start".

Step 4: Stop the Data Collector Set

1. Right click on the Data Collector Set created in Step 2.
2. Select "Stop".

HOWTO: Change the User for the Data Collector Set

1. Open Performance Monitor (See Step 1).
2. Expand the "Data Collector Sets" node.
3. Expand the "User Defined" node.
4. Right click the Data Collector Set for which you wish to change the user.
5. Select "Properties".
6. Under the "General" tab, click the "Change" button found in the "Run As" section.
7. Provide a username and password for the account that will be running the Data Collector Set.
8. Click the "OK" button.
9. Click the "Apply" button.
10. Click the "OK" button.

HOWTO: Change the Log file Location

1. Open Performance Monitor (See Step 1).
2. Expand the "Data Collector Sets" node.
3. Expand the "User Defined" node.
4. Right click the Data Collector Set for which you wish to change the user.
5. Select "Properties".
6. Under the "Directory" tab, click the "Browse" button.
7. Select the folder location in the "Browse for Folder" dialog.
8. Click the "OK" button.
9. Click the "Apply" button.
10. Click the "OK" button.

HOWTO: Create a Data Collector Set Template

Once a custom Data Collector Set has been created, it can be saved as a template:

1. Open Performance Monitor (See Step 1).
2. Expand the "Data Collector Sets" node.
3. Expand the "User Defined" node.
4. Right Click on the Data Collector Set name that will be used as a template.
5. Left click "Save Template...".
6. Provide a file name.
7. OPTIONAL: Browse to a folder location where the template will be stored.

The template is stored as XML, making it easily editable in any text editor (IE: Notepad, Wordpad, etc). However, the counters are not entirely editable and will likely require recreation.

HOWTO: Use a Custom Template to Create a Data Collector Set

1. Open Performance Monitor (See Step 1).
2. Expand the "Data Collector Sets" node.
3. Right click "User Defined", and select "New > Data Collector Set".
4. Specify a unique name.
5. Select the "Create from a template (Recommended)" radio button.
6. Click the "Next" button.
7. Click the "Browse" button.
8. Navigate to the folder where the custom template is located.
9. Select the template file.
10. Click the "Open" button.
11. Click the "Next" button.
12. OPTIONAL: Change the log location.
13. Click the "Next" button.
14. OPTIONAL: Change the user account this Data Collector Set will use for credentials.
15. Click the "Finish" button.

SQL Server 2008 R2 Performance Monitoring

Posted on January 19, 2011 by mssqldude

In case you are not aware, there are several tools that SQL Server 2008 R2 provides for you as a DBA to use that allow you to monitor performance on your databases. I’ve been talking a lot about these to customers recently and will touch on this next week at the South Jersey SQL Server User group: http://bit.ly/gtponF.
Some of these tools are just there and you may not ever open them or you may be on a previous version of SQL Server.
1. Management Data Warehouse
This one has gone through a few revisions and is an excellent part of the SQL Server 2008 R2 toolset that you can configure to run on your SQL Server simply by right-click and selecting “Configure Management Data Warehouse” on the Data Collector sets in your instance “Management” folder. The data collectors are configurable and will collect stats, typically at 15 minute intervals, across your instance databases for queries, server stats and disk stats. The MDW will also manage the archival of data history such that you can configure how much history to maintain online. Since this is a “data warehouse” and is based on data collectors that activate at set intervals, or on requested execution, the MDW is very good at providing history and baselines. In addition, the reports are all based on SSRS and include a rich set of reports out of the box that include drill-down to query text and query plans. Since these are SQL Server Reporting Services based performance reports for SQL Server, you can create your own MDW reports in SSRS as custom reports.

2. Utility Control Point
UCP is brand new in SQL Server 2008 R2 and with a single Data Center edition of the database, you can stand-up a monitoring server using just SQL Server and stay within SQL Server Management Studio. There are interactive dashboards that allow you to monitor SQL Server 2008 R2 databases using the data collectors mentioned above in MDW also within SSMS, making both of these closely related to each other and very easy for a SQL Server DBA because you can stay within your Management Studio environment.
In both the case of MDW reports and UCP, data is collected and pushed into a data warehouse and you should be cognizant of a possible hit to performance as well as data storage with all of these counters that are collected, processed and stored. UCP is a good candidate to stand alone in your environment and manage the servers centrally here.

3. Activity Monitor
Another tool that has gone through many SQL Server revisions, the SQL Server 2008 R2 version of Activity Monitor. Like MDW, you can get performance stats wih query details in the activity monitor. But unlike data collector driven tools like MDW & UCP, Activity Monitor produces real-time results in areas such as waits, processes and expensive queries. And unlike a data warehouse, the data is not persisted. The monitoring begins when you open Activity Monitor and ends when you close it.

Fonte:  mssqldude

Error 502 “Active FTP not Allowed” when trying to list files in a FTP session behind Forefront TMG 2010

Error 502 “Active FTP not Allowed” when trying to list files in a FTP session behind Forefront TMG 2010

Yuri Diogenes [MSFT]

16 Mar 2010 4:26 PM

• 13

Consider a scenario where you have a client workstation behind Forefront TMG 2010 and you are trying to download files from a FTP Server. You are successfully able to logon on the FTP but after type the command “dir” you get the error message below:

The message is pretty clear about what is going on, isn’t it? Well, it is but where do I enable this option? I don’t remember having this on ISA!! To address this issue you just need to enable a new option that we have on TMG, this option is located on the FTP Filter properties as shown below:

After enabling this option and apply the changes you should be able to list your files just fine. It is important to mention that this setting has nothing to do with the FTP Read Only option, that you had in ISA 2004/2006 and still have it on TMG. The FTP Filter when running in read only mode (see figure below) will blocks all commands in the control channel except the following ones:
“ABOR, ACCT, CDUP, CWD /0, FEAT, HELP, LANG, LIST, MODE, NLST, NOOP, PASS, PASV, PORT, PWD /0, QUIT, REIN, REST, RETR, SITE, STRU, SYST, TYPE, USER, XDUP, XCWD, XPWD, SMNT”

You can customize this list by using the sample script below (from Configuring Add-ins MSDN article),in this example the script configures FTP Access Filter to allow only the USER and PASS commands:

Dim root Dim ftpFilter Dim vpSet On Error Resume Next Err.Clear Set root = CreateObject("FPC.Root") ' Get the filter's administration object Set ftpFilter = root.GetContainingArray.Extensions.ApplicationFilters("{680A928F-22B3-11d1-B026-0000F87750CB}") If ftpFilter Is Nothing Then     Wscript.Echo "FTP Access Filter ({680A928F-22B3-11D1-B026-0000F87750CB}) is not installed in array."     WScript.Quit End If ' Get the vendor parameter set containing the filter's configuration. Set vpSet = ftpFilter.VendorParametersSets.Item("{680A928F-22B3-11D1-B026-0000F87750CB}") 'If this vendor parameters set does not exist, create it. If vpSet Is Nothing Then     WScript.Echo "Adding a vendor parameters set ({680A928F-22B3-11D1-B026-0000F87750CB})"     Err.Clear     Set vpSet = ftpFilter.VendorParametersSets.Add("{680A928F-22B3-11D1-B026-0000F87750CB}",False)     ftpFilter.VendorParametersSets.Save End If ' Add the required parameter. vpSet.Value("AllowReadCommands") = "USER PASS" vpSet.Save

Note: don’t change the default Read Only commands unless you have a real business need for that.

HOW TO: Copy Exchange 2010 Receive Connectors

Copy Exchange 2010 Receive Connectors

Posted by Chris on 25 January 2011, 10:04 am

In deploying a second Exchange 2010 server I found myself needing to duplicate a receive connector with about 20 different IP entries. Being lazy (or as Terence called it; efficient), I started googling and found this post by Terence Luk. His procedure works, but I figured there had to be a faster way. After a few minutes of fiddling I managed to compress his technique into this one-liner:

1	New-ReceiveConnector "Mail from Printers" -Server EX02 -Bindings 0.0.0.0:25 -RemoteIPRanges ( Get-ReceiveConnector "EX01\Mail from Printers" ).RemoteIPRanges

Exchange 2003, 2007 & 2010 Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC)

Exchange 2003, 2007 & 2010 Topology discovery failed, error 0x80040a02 (DSC_E_NO_SUITABLE_CDC)

A client has been struggling with Exchange 2003 for some time now and I’ve got the project to roll out Exchange 2010. The first hurdle I come to is a new incarnation of a pre-existing problem from Exchange 2003 – simply put “Can’t find a domain controller”. Which means it can’t mount the Information Store. Brill.

You’ll need to edit the Default Domain Controllers Policy in Group Policy.

1. Computer Configuration
2. Windows Settings
3. Security Settings
4. User Rights Assignment
5. Mange auditing and security log

Add “Exchange Servers” or “Exchange Enterprise Servers” to that policy.
gpupdate /force on the domain controller and restart the Exchange Services