The release of VMware PowerCLI 10.0.0 was another big one for us. As a result, PowerCLI is now available on Linux, MacOS, and Windows! As part of every major release, there’s a large number of asks for the PowerCLI poster and today we’re releasing it!
The poster features a bit of a layout refresh which conforms to a more standardized poster sizing guideline, but still features all of our cmdlets, some basic examples, and links to helpful resources.
This script checks various configuration items on the server to make sure they match the recommendations published in the “Exchange 2013 Sizing and Configuration Recommendations” guidance on TechNet. It also reports on OS, system, and hardware information. It can be ran remotely, against a single server or a group of servers. It takes some of the most common configuration causes of Exchange 2013 performance cases that we encounter in support and allows you to rule them out quickly without having to check each server or read through the entire TechNet guidance.
This script needs to be executed from the Exchange 2013 Management Shell.
Here is a current list of items the script reports on:
Operation System version
Server Manufacturer and Model (physical hardware only)
VM host processor/memory configuration recommendations
Exchange server roles
.NET Framework version
Network card name and speed
Network card driver date and version (Windows 2012 and Windows 2012 R2 only)
RSS enabled (Windows 2012 and Windows 2012 R2 only)
Physical Memory amount
Number of processors, cores, and core speed
Processor speed being throttled
Current list of active/passive databases and mailboxes (optional)
I see a lot problems with to small log disks. Sizing Exchange is a very imported thing!! Today there a lot of problems with Thiry-Party Devices. They can create a lot of log files if you run a oudated Exchange Server. Transaction logs are truncated when backup software successfully backs up an Exchange server. The ‘Backup/Truncation Failure Tolerance’ field in the Backup Configuration section, allows a value to be set that specifies how much capacity will be available for logs in the event of backup failures or issues with Thirth party devices. The default value is 3 days. Change This!! This ensures that the server will continue to function and you have the ability to restore from transaction logs for x days, if the backup fails & and if some thirth party device give some trouble. Logs disk & backup should be monitored to ensure that they are successful.