Window 7 desktop features you didn’t know you had

When defining a Windows desktop configuration, many administrators start with a default Windows deployment and then lock down the settings and features they don’t want users to access. While this approach works, it’s based on the assumption that a default installation includes all of the features available for that particular version of the operating system.
This isn’t necessarily the case.

Windows 7 has several useful features that are not installed by default; some of them could benefit your organization.

To access these nondefault features, open the Control Panel and click on Programs. In the Programs and Features section, click the Turn Windows Features On or Off link. When you do this, Windows will display a dialog box where you can enable or disable several features.

While you may not want to enable all the features, here are a handful of nondefault components to consider.

  • The Indexing Service
  • Internet Information Services
  • Internet Information Services Hostable Web Core
  • Microsoft Message Queue Server
  • RIP Listener
  • Microsoft Services for Network File System
  • Simple Network Management Protocol
  • Simple TCP/IP services
  • Subsystem for Unix-based Applications
  • Telnet Server
  • TFTP Client
  • Windows TIFF IFilter

 While some of these nondefault components are outdated or relatively obscure, others may be useful in your environment.

 

Go through link for more information http://searchenterprisedesktop.techtarget.com/tip/0,289483,sid192_gci1520579,00.html?track=NL-1108&ad=787188&asrc=EM_NLT_12535528&uid=6118318

Throttling PowerShell command usage in Exchange 2010

Throttling PowerShell command usage in Exchange 2010



Administrative actions are based on PowerShell. Some administrative actions, like running large scripts, can be resource intensive. Throttling PowerShell can help lessen the strain on a server’s performance.


Exchange’s Web services (EWS) rely on remote shell sessions. Because of this, throttling PowerShell can help prevent a user from overloading Exchange by performing concurrent actions through multiple browsers.


Exchange Server 2010 provides several different parameters you can use to throttle PowerShell command usage. One such parameter is PowerShellMaxConcurrency. This parameter can be tricky because its function varies depending on the context.


When a user establishes a remote shell, the PowerShellMaxConcurrency parameter defines the maximum number of simultaneous remote shell sessions that a user can have open. This parameter may also be applied to EWS. In this case, the parameter controls the maximum number of cmdlets that a user can simultaneously run.


Where PowerShell throttling and throttling policy parameters differ

Unlike the PercentTimeIn parameter, PowerShell throttling parameters don’t automatically assume that you want to throttle commands based on percentages of a minute. Instead, you must explicitly define your desired throttling time period by assigning a period of time (in seconds) to the PowerShellMaxCmdletsTimePeriod parameter. After doing this, you can control the maximum number of PowerShell cmdlets that are allowed to run within the designated period by assigning a value to the PowerShellMaxCmdlets parameter.

One PowerShell throttling parameter that I recommend avoiding is PowerShellMaxCmdletQueueDepth, which controls the total number of PowerShell cmdlets that can be simultaneously queued. Using this parameter can have several side effects.


Modifying the PowerShellMaxCmdletQueueDepth parameter affects PowerShellMaxCmdlets and PowerShellMaxConcurrency settings, both of which already skew cmdlet depth. The PoweShellMaxConcurrency parameter limits the number of concurrent remote shell sessions that a user can have open, so it also limits the number of simultaneous cmdlets that can run. The parameter can also limit the number of browser sessions that a user can have open.


When you’re using the PowerShellMaxCmdletQueueDepth parameter, it has the same effect as decreasing the PowerShellMaxConcurrency setting by two. If you do decide to use this parameter, Microsoft recommends that you set its value to at least three times the value of the PowerShellMaxConcurrency parameter.


Note: Throttling the PowerShellMaxCmdletQueueDepth won’t affect the Exchange Control Panel or EWS.