After some wait Exchange server 2010 Service Pack 1 is now released.
Read about all the new and improved features here
Download it here and read the release note very carefully before installing.
happy patching
... words from a messaging guy
After some wait Exchange server 2010 Service Pack 1 is now released.
Read about all the new and improved features here
Download it here and read the release note very carefully before installing.
happy patching
CU6 for OCS 2007 R2 was released a couple of weeks ago. OCS 2007 R2 CU6
The simplest way of installing is to download and run the ServerUpdateInstaller. This will install all of the needed patches to your OCS server.
Unfortunately there is a problem that you might encounter when doing so. The FrontEnd service will not start and you will se this in the eventlog. “The Office Communications Server Front-End service terminated with service-specific error 3287186749 (0xC3EE7D3D).”. Reason is that serverinstaller does not contain all updates needed. The FrontEnd server patch needs an updated database to run correctly.
What you need to do is to ununstall KB983472 and then install the OCS2009-DBUpgrade.msi to upgrade the databases used by OCS.
OCS2009-DBUpgrade.msi is found in KB 2032834, Description of the cumulative update package for Office Communications Server 2007 R2 database: July, 2010
After databases have been upgraded you can reinstall KB983472 or simply run serverinstaller again and since databases are updated, the OCS FrontEnd service will start normally.
For many generations, Outlook Web Access allowed users to change their password, but only after they had successfully logged on to OWA. With Exchange 2007 Service Pack 3 and the upcoming Exchange 2010 Service Pack 1, administrators now have the ability to change the password pretty much the same way users do when they log on to Windows on their PC.
This enables administrators to set the bit to force users to change their password the next time they logon. This new feature also lets users change their password after it has expired, without having to call the helpdesk for assistance.
How does it work?
First users are presented with the ordinary OWA logon form.
If the account is being forced to change its password, a new form will be displayed that contains fields for the account name and new and old passwords.
If the user fills in everything correctly, then they will be presented with a status form simply saying their password was changed.
After pressing the OK button, the user will be presented with the ordinary logon form again so they can logon with the newly set password.
Enable password change functionality.
Changing passwords in this manner has to be enabled – it is not enabled by default. This is done by setting a bit in registry on your CAS servers.
In the “HKLM\SYSTEM\CurrentControlSet\Services\MSExchange OWA” subkey, create a DWORD (if needed) named ChangeExpiredPasswordEnabled and give it a value of 1 (one) to enable the functionality, and 0 (zero) to disable.
After you change the registry value, you must do a “iisreset /noforce” to activate the new setting.
Now all you administrators can sit back, relax, and enjoy letting peoples’ passwords expire or setting the “User must change password at next logon.” (Even though we all know that the chances of the user calling the help desk anyway are still pretty high!)
Consider authentication method.
Rest password functionality will only work if you have Forms Based Authentication enabled on CAS.
If you’re protecting CAS with ISA/TMG and doing FBA on ISA/TMG, then you probably have authentication set to Basic or Windows Integrated on CAS, so this functionality will not be enabled.
To solve this, enable the change password functionality on ISA/TMG: http://blogs.technet.com/b/sooraj-sec/archive/2009/12/20/password-change-with-isa-server-2006.aspx (However, if you ask me this method does not perform the password reset functionality as nicely as Exchange OWA.)
Another way to solve this is to change how OWA is published by enabling FBA with the new password reset functionality on CAS and not performing the authentication on ISA/TMG. On the other hand, this workaround could raise some security concerns so I urge you to look closely at all your options before choosing the password reset method that best suits your company’s needs.
I hope that this tutorial on OWA password reset changes in Exchange 2007 SP 3 and 2010 SP 1 has been informative for you. Now that administrators can reset OWA passwords easily, or even better allow users to reset their own passwords, it should no doubt reduce the volume of calls the help desk receives.
When rearranging and upgrading to never OS it’s very common to install a new DC and then remove the old one instead of doing in place upgrade. This is all fine Active Directory wise. Exchange Server itself will dynamically detect new and removed Domain Controllers and Global Catalog servers and adjust accordingly but Exchange Management Console is not dynamic in the same way.
Symptoms is when you start or navigate in EMC you get error messages indicating error in LDAP query or missing Domain Controllers.
You might also see error messages in the Application log indicating unavailable LDAP or DC/GC.
Why is this happening?
EMC caches Domain Controller names in the MMC temporary files and unfortunately it will not be clever enough to query another DC or GC when the current one is not responding or has been removed.
How to solve the problem?
Solution is quite easy: clear the MMC cache.
Close all open MMC. Start a new empty MMC, in the menu, select File/Options and then on the Options Window and Disk Cleanup tab, press the “Delete Files” button. Close the empty MMC.
Next time you start EMC it has no cache to read from and will dynamically select a new DC.
There is another way of doing this. Close all open MMC and then delete the file “C:\Users\%username%\AppData\Roaming\Microsoft\MMC\Exchange Management Console”.
As you can see this cache is per user which unless the administrator creates a process of clearing the cache when needed, each user that runs EMC must clear the cache itself.
If you’re interested, “C:\Users\%username%\AppData\Roaming\Microsoft\MMC\Exchange Management Console” file is in XML format and can be viewed if you like, but I wouldn’t advice you to make any changes to it.
Microsoft has now released Exchange Server 2007 Service Pack 3.
With SP3 it is now possible to run Exchange 2007 on Windows Server 2008 R2.
Download Exchange 2007 SP3 from here
The link with what’s new in Exchange seems to be incorrect. but here it is anyway http://go.microsoft.com/fwlink/?LinkId=154404
Don’t run of and upgrade your OS to Windows Server 2008 R2 because of this. It’s most likely not supported when Exchange is installed.
Happy patching