Clean up Winsxs folder on Windows 2008 R2 SP1

Starting from Service Pack 1, Windows 2008 R2 and Windows 7 finally has a built-in tool to reduce the size of the Windows Side-by-Side DLL repository and free up some GBs on your server storage. This tool is DISM.exe.

The procedure is the following:

Install Windows Service Pack 1 then ...

Start and elevated command prompt (run 'CMD' as administrator) and ...

Run the DISM command, which replaces the old VSP1CLN and COMPCLN we used on previous Windows versions:

DISM.exe /online /Cleanup-Image /spsuperseded

Wait 10 minutes before the task completes ( it ends with “Service Pack Cleanup operation completed. The operation completed successfully”)

Normally you should have been able to reduce the Winsxs folder size by 1 or maybe 2 GBs, sometimes more. Saved space may vary a lot.

Just know that after using DISM you will not be able to uninstall the Service Pack 1 anymore.

Let's have a look at the used switches for DISM.exe:

The /online switch tells DISM to work on the running OS installation
The /spsuperseded option removes the backup files created during installation.


Optionally you could use the /hidesp option which will remove SP1 (KB976932) from the “Installed Updates” section of Programs and Features, to ensure that users do not try to uninstall the Service Pack.

Exchange 2010 SP1 Password Reset Tool

Now that SP1 for Exchange 2010 is released, it is time to start exploring some of the new features. The first in line is the newly release password reset tool (this was also included in Exchange 2007 SP3). 

This has been a long awaited feature since OWA has been in use. For users that primarily use OWA for email access or are primarily remote access users, administrators have always struggled with resetting user’s password that will force users to change at first logon. Also users have struggled with remembering to reset their passwords through OWA before the password expired since their was no warning integrated with OWA.
The following is the setting within the user account that forces the user to change their password at next logon:

When a user tried to login to OWA with an expired password or configured to change their password at next logon, the user would see the following error: “The user name or password you entered isn’t correct. Try entering it again”

The Password Reset Tool feature is not active by default. To activate this feature within Exchange 2010 SP1 (or Exchange 2007 SP3), all that is needed is one registry key:
HKLM\SYSTEM\CurrentControlSet\Services\MSExchange OWA
Create DWORD: ChangeExpiredPasswordEnabled with value: 1

After creating the registry entry, an IISReset must be performed. Now under the same scenario, if a user is configured to change their password at next logon or if their password has expired, the user will see the new message: “Your password has expired and you need to change it before you sign in to Outlook Web App.”

Now the user can change their password before logging into OWA:

But that is not all…If a user’s password is set to expire within 14 days, a user will see a warning while they are logged into OWA and will have the option to reset their password:



Source

Brand OWA 2007 and 2010 with the Server Name

How to Brand OWA 2007, 2010 and 2013 with the Server Name

If your Exchange 2007 or Exchange 2010 and 2013 environment includes more that one CAS server, it's sometimes helpful to know which one a client is connecting to.  Environments with more that one CAS usually use some form of hardware or software load balancing, making it difficult to troubleshoot OWA issues.

A relatively easy way to do this is to brand each CAS server's OWA logon page with the server name.  This way, end-users are able to provide the server name if they run into problems.

For Exchange 2007, navigate to C:\Program Files\Microsoft\Exchange Server\ClientAccess\owa\auth folder and open the logon.aspx file using Notepad.

Add either of the two edits shown in the screenshot below:

Adding the server name as highlighted above in red will visibly add the server name to the logon screen, as shown below:

Adding the server name as highlighted above in blue will add the server name "invisibly" below the logon screen.  To view the server name, click anywhere on the screen and press CTRL-A to select all.  You can then see the server name, as shown below:

For Exchange 2010, navigate to the C:\Program Files\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth folder and open the logon.aspx file using Notepad.


Add the server name, as shown in the screenshot below:

This will add the server name to the logon screen, as shown below:

For Exchange 2013, navigate to the C:\Program Files\Microsoft\Exchange Server\V15\FrontEnd\HttpProxy\owa\auth folder and open the logon.aspx file using Notepad. In my example i used Notepad++ so you can see the line number.

On line 272 add: <p><span style="color: #ffffff;">servername</span></p>

Edit:

I added a personal touch to the 2010 option, at the very end of the logon.aspx page add the line:

<p><span style="color: #ffffff;">SERVERNAME</span></p>

This line will be invisible on the loginpage until you select ctrl + a.

Important Note: These edits are overwritten anytime an Exchange Server update is applied to the CAS servers.  This is because every update includes a complete reinstallation of the Exchange binaries, and the logon.aspx file you edited will be overwritten.

Typically, the logon.aspx page rarely changes, so you can usually make a copy of it after you've made your edits and copy it back after the update.  However, there are no guarantees that the file will not be changed by an update.  If so, you will need to re-edit the logon.aspx file.

Source

Best Practice for RPC Timeouts in Exchange

Exchange 2010 and 2007 use RPC (Remote Procedure Calls) for all client and RPC proxy calls. For example, email clients (Outlook, Outlook Anywhere (OA), and ActiveSync) use RPC for MAPI connectivity.

The default keep alive time for RPC connections uses the IIS idle connection timeout, which is 15 minutes. This usually doesn't cause a problem on local LAN or WAN connections, but routers and switches that are used to connect Internet clients to internal Exchange servers often have more aggressive timeouts. Typically these network devices have a 5 minute timeout which causes problems for external clients, particularly Outlook Anywhere, iPhone, and iPad clients. Symptoms include messages stuck in the Outbox and poor email performance on the remote clients, and high CPU utilization on the Exchange Client Access Servers (CAS).

The new best practice is to adjust the RPC keep alive timeout value on the Client Access Server from 15 minutes to 2 minutes. Since RPC is a function of Windows, not Exchange, this value is adjusted under the Windows NT registry key. The value is located here:

HKLM\Software\Policies\Microsoft\Windows NT\RPC\MinimumConnectionTimeout

Normally the MinimumConnectionTimeout DWORD value does not exist, which means RPC uses the default value of 900 seconds (15 minutes). To adjust it, create or modify the MinimumConnectionTimeout value and set the value to decimal 120 (seconds, or 2 minutes). IIS must be restarted on the CAS to affect the change.

The following command will create the appropriate values:

reg add "HKLM\Software\Policies\Microsoft\Windows NT\RPC" -v "MinimumConnectionTimeout" -t REG_DWORD -d 120

The Outlook and ActiveSync clients honor this new timeout during the connection to the CAS, so both client and server now send a Keep-Alive packet after two minutes of inactivity, effectively maintaining both TCP connections needed.

A colleague of mine works for a large global company that was affected by this. They have several thousand iPads connecting to nine load balanced CAS servers and all the CAS were peaking at 100% CPU utilization. Once they implemented this change the average load on the CAS is now 20-30% and the iPad performance is much improved.

This is my new best practice and I make this change on every Exchange CAS deployment. For more information about RPC over HTTP see Configuring Computers for RPC over HTTP on TechNet.

Source

Outlook Anywhere RPC over HTTP

Symptoms:

Attempting to ping RPC endpoint 6001 (Exchange Information Store) on server server.contoso.com.
The attempt to ping the endpoint failed.
Additional Details An RPC error was thrown by the RPC Runtime process.
Error 1818 CallCancelled

Source

On the Mailbox servers: a DWORD entry needs to be created on each Mailbox server named "Do Not Refer HTTP to DSProxy" at HKLM\System\CCS\Services\MSExchangeSA\Parameters\ and the value set to "1".
Next, as indicated earlier, the RPCProxy will block access to the DC servers unless there servers are included in the ValidPorts regkey.
So, set the following on the Client Access Servers:
1.The ValidPorts setting at HKLM\Software\Microsoft\RPC\RPCProxy needs setting so that the entries referring to 6004 point to DC servers in addition to the mailbox server.
2.The PeriodicPollingMinutes key at HKEY_LOCAL_MACHINE\System\CurrentControlSet\Services\MSExchangeServiceHost\RpcHttpConfigurator\ needs setting to zero to prevent RpcHttpConfigurator from updating the Valid Ports key automatically.
Finally, you need to make sure that the DCs are listening on port 6004:
On the Global Catalog servers: a REG_MULTI_SZ entry needs to be created on each GC named NSPI interface protocol sequences at HKLM\System\CCS\Services\NTDS\Parameters\ and the value set to ncacn_http:6004.
There is 1 last thing to deal with in this SSL-ID load balanced configuration.
Outlook profile creation hard codes a call to DSProxy on 6004.
Which means that we can get split connectivity during profile creation.
To deal with this minimal volume of traffic, there is 1 final regkey that should be set on the mailbox servers:
On the Mailbox Servers - set the HKLM\System\CCS\Services\MSExchangeSA \Parameters key "NSPI Target Server" to the FQDN of the DC that profile creation should use.
By using only 1 DC for profile creation, all DSProxy calls will be proxied into that single DC, once again avoiding split connectivity.

Source

Script to Force Download of the Lync 2010 Address Book

I wrote a script (batch file, really) that users can run to force a download of the Lync address book. 

The Lync address book is generated automatically on the Lync server every 24 hours at 1:30AM, local server time. You can use the Update-CsAddressBook cmdlet on the Lync server to force the server to update the address book. You will need to wait 5 minutes for the server to run the update. Look for Lync Server event 21056 from LS Address Book Server to confirm that the address book update has completed, as shown below:

The address book is then downloaded locally by the Lync client in a randomized schedule from 1 to 60 minutes after the the user signs in. Lync Server MVP Jeff Schertz wrote about this process in great detail in his post, Updating the Lync 2010 Address Book.

My script sets a GALDownloadInitialDelay key in the registry to force the Lync client to download the address book immediately after signing in. It then enumerates all the SIP_* folders in the C:\Users\username\AppData\Local\Microsoft\Communicator folder and deletes the GalContacts.db and GalContacts.db.idx files which make up the Lync address book.

@echo off
echo Clearing Lync Address Books...
reg add HKCU\Software\Policies\Microsoft\Communicator /v GALDownloadInitialDelay /t REG_DWORD /d 0 /f
If %errorlevel%==1 goto Error
if "%LOCALAPPDATA%"=="" Set LOCALAPPDATA=%USERPROFILE%\Local Settings\Application Data
dir "%LOCALAPPDATA%\Microsoft\Communicator\sip_*" /b > list.txt
FOR /F "tokens=1" %%i in (list.txt) do del "%LOCALAPPDATA%\Microsoft\Communicator\%%i\gal*.*"
echo.
echo Sign out of Lync and sign back in to download the current address book.
goto End
:Error
echo You must run this command from an elevated Command Prompt.
echo.
:End

Save the script above as ClearLyncAddressBook.bat and run it from an elevated Command Prompt. Then sign out and back into Lync and the address book will download immediately.

 

 

Source

Test-ExchangeServerHealth – PowerShell Script to Generate a Health Check Report for Exchange Server 2010

I recently came across this great script, thats shows you in an email how your Exchange environment is performing.

 

 

A few months ago I released an Exchange 2010 mailbox server health check script.

While the script was useful it lacked a few important things. For one thing, it only checked the mailbox server role. Also, the results were only output to the shell session, not in object form, so there wasn’t much that could be done with the results.

Today I’ve released a totally overhauled and updated version of the script that addresses those problems. Before you run the script please read the guidance below, watch the demo video, and check the known bugs and FAQ at the end of this article for current issues.

 

Download the script file here: Test-ExchangeServerHealth.ps1

 

The Test-ExchangeServerHealth.ps1 script is run from the Exchange Management Shell. You can use a few builtin parameters to control what it does.

 

.PARAMETER server
Perform a health check of a single server

.PARAMETER reportmode
Set to $true to generate a HTML report. A default file name is used if none is 

specified.

.PARAMETER reportfile
Allows you to specify a different HTML report file name than the default. 

Implies -reportmode:$true

.PARAMETER sendemail
Sends the HTML report via email using the SMTP configuration within the script. 

Implies -reportmode:$true

 

If you use the report mode you’ll get a HTML file containing the health check results, and/or an email to your designated address if you also use the send email option.

For the email functionality to work please update these variables in the script to suit your environment.

 

#...................................
# Email Settings
#...................................

$smtpServer = "ho-ex2010-mb1.exchangeserverpro.net"
$smtpTo = "administrator@exchangeserverpro.net"
$smtpFrom = "healthcheck@exchangeserverpro.net"
$messagesubject = "Exchange Server Health Check - $date"

 

Here is a demo video explaining how the different options work.

 

Download the script file here: Test-ExchangeServerHealth.ps1

 

Please feel free to download and try the script.

 

If you’re looking for an example of how to schedule the script to run using Task Scheduler please see this article.

Change Log:

• V1.0, 5/07/2012 – Initial version
  V1.1, 5/08/2012 – Minor bug fixes and removed Edge Tranport checks

Bugs list and FAQ

Q: Which version of PowerShell is required?

Version 2.0 or higher. If you are running the script on a server that has Exchange 2010 roles or management tools installed then it will have v2.0. If you are running on an Exchange 2007 server check first whether v2.0 is installed. I don’t test the script on v1.0 but you are welcome to modify it as necessary to get it running on a v1.0 environment.

Q: Why do I get an error when the script sends the email report?

Make sure you’ve configured the $smtpserver variable in the Email Settings section of the script to point to a Hub Transport that either accepts anonymous users (typically an internet-facing Hub Transport), or if you’re using a separate management server or admin workstation point the $smtpserver to a Hub Transport that has a receive connector set up that the server you’re running the script on is allowed to relay through.

Q: Why is there an error when the script checks the queue for Exchange 2007 Hub Transport servers?

This is a bug that I am working on. The script was not originally intended to be backwards compatible but I will do my best to fix this bug.

Q: Why do I get errors when the script checks my Edge Transport servers?

Between firewalls and permissions the Edge Transport checks are difficult to account for so in the next version the Edge Transport role will simply be skipped by the script.

Q: Why do I get an error on the server uptime check?

This is a bug that I am working to reproduce and eliminate.

Q: What should I do when the script report an error/fail on my servers?

The script doesn’t perform any diagnostics when it detects an error, it only reports them to you. When you see an error you should investigate further using the management tools and cmdlets that are provided by Exchange.

If you are encountering situations where the script reports errors that turn out to be false alarms please let me know and I will do my best eliminate those false alarms.

Q: Can you add feature X to the script?

Currently I am working on the following feature improvements:

• DAG/database copy health
• Ability to specify a file name containing a static list of servers to check

If you have other health check related features you’d like to see included please let me know in the comments below.

 

Source

Enabling and disabling Outlook Anywhere Per User

RPC/HTTPS was the first name when outlook anywhere access was introduced with Exchange Server 2003. Exchange 2003 did not provide a very granular control on it though. With increase in productivity it also brought a concern with it. It could allow configuring user’s mailbox on any outlook client even if the user was not supposed to do it.
Result, people could make unauthorized copies of their mailboxes on their home PCs and laptops.
Exchange 2007 SP1 and later has a great feature of disabling outlook anywhere access per user basis.

It is a very simple process of running few commands in powershell and the administrator is done with the configuration. Lets take a look:

To enable outlook anywhere for a single user:
Get-Mailbox –Identity "username" | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$False

To disable outlook anywhere for a single user:
Get-Mailbox –Identity "username" | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$True

To enable it for all users:
Get-Mailbox –ResultSize Unlimited | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$False

To disable it for all users:
Get-Mailbox –ResultSize Unlimited | Set-CASMailbox -MAPIBlockOutlookRpcHttp:$True

To enable it for multiple users only:

• Identify the user who need to be blocked access to Outlook Anywhere.
• Make a list of all such user’s user accounts.
• Put it in a simple text file as below:

User1
User2
User3

• Now save this text file to any location you want with name Mailboxes.txt. For example D:Mailboxes.txt
• Simply run the script below.

$Mailboxes = Get-Content D:Mailboxes.txt
Foreach ($Mailbox in $Mailboxes)
{
Set-CASMailbox -Identity $Mailbox -MAPIBlockOutlookRpcHttp:$false -Verbose
}

To disable it for multiple users only:

• Identify the user who need to be blocked access to Outlook Anywhere.
• Make a list of all such user’s user accounts.
• Put it in a simple text file as below:

User1
User2
User3

• Now save this text file to any location you want with name Mailboxes.txt. In my case it is D:Mailboxes.txt
• Simply run the script below.

$Mailboxes = Get-Content D:Mailboxes.txt
Foreach ($Mailbox in $Mailboxes)
{
Set-CASMailbox -Identity $Mailbox -MAPIBlockOutlookRpcHttp:$true -Verbose
}

Source

How to increase the maximum simultaneous move-requests in Exchange Server 2010

As of Exchange Server 2010 we no longer have the ability to use the cmd-let Move-Mailbox and specify the -Maxthread ability to change how many mailboxes to move simultaneous.

In Exchange Server 2010 we now use New-MoveRequest and default it moves 5 mailboxes at the same time. For 1500 mailboxes it could take days.

To change the maximum number of simultaneous moves we must on every CAS server edit the file:

MSExchangeMailboxReplication.exe.config

Under the MRSConfiguration section change these fields into a desired value:

MaxActiveMovesPerSourceMDB = "25"
MaxActiveMovesPerTargetMDB = "25"
MaxActiveMovesPerSourceServer = "50"
MaxActiveMovesPerTargetServer = "25"
MaxTotalMovesPerMRS = "100"

Now we must restart the Microsoft Exchange Mailbox Replication Service.
From Powershell:

restart-service MSExchangeMailboxReplication

Source

How to add a "Sign In Again" button to the Exchange 2010 OWA Sign Out page

By default when you click "Sign Out" in OWA 2010, Exchange 2010 directs you to a page that explains that you have successfully logged off from Outlook Web Access. The only button available, "Close Window", closes the existing browser window or tab. This article explains how to add a "Sign In Again" button to the logoff.aspx page, as shown below:

To add the Sign In Again button, follow these steps on each Exchange 2010 Client Access Server (CAS):

• Logon to the CAS using a local Administrator account.
• Using Windows Explorer, navigate to the %ProgramFiles%\Microsoft\Exchange Server\V14\ClientAccess\Owa\auth folder and make a copy of the logoff.aspx file for backup.
• Edit the logoff.aspx file using Notepad.
• Use Find to search for the word logoffclose. In Exchange 2010 SP1 beta this will be line 123.
• Insert the following code before this line, as a single line:

<input id="btnCls" type="submit" class="btn" title="Click here to sign in again." value="Sign In Again" onclick="window.navigate('/owa')" onmouseover="this.className='btnOnMseOvr'" onmouseout="this.className='btn'" onmousedown="this.className='btnOnMseDwn'">

• Save the logoff.aspx file.
• Copy the new logoff.aspx file to the same file path on all your 2010 CAS servers.

Remember that applying any Exchange 2010 Service Pack or Update Rollup to your CAS servers will overwrite the login changes you made, so create a copy of the edited logoff.aspx file to reapply the Logon Again button after the update. Also know that Service Packs and Update Rollups could possibly include changes to the logoff.aspx page, so you may need to follow these steps again to edit the new page included in the update.

Edit:

You can also add the following line to get the redirection automatically.

<--- start of the snippet-->
window.navigate('https://<servername>/owa')         
Owa.ExecCommand.execute(document, "ClearAuthenticationCache", false);
<--- end of the snippet-->

And for Firefox users:

<--- start of the snippet-->
window.location('https://<servername>/owa')         
Owa.ExecCommand.execute(document, "ClearAuthenticationCache", false);
<--- end of the snippet-->

 

Source