I recently downloaded a new version of Adobe Flash Player or possibly Adobe Reader. Imagine my surprise when the Adobe Download Manager reports that in addition to installing Flash, it also installed McAfee Security Scan Plus. At the time I assumed that perhaps this was done only to secure the download process and didn't think much of it. At the time I did not see an option to not select this software, but it may have been there.
It turns out that this is security scanning software from McAfee. And while it is legitimate software, it only scans for threats and does not prevent or remove them. On their web page it is promoted as a "Free Download" and it "Actively checks your computer for anti-virus software, firewall protection, and web security, and threats in your open applications."
On the same page is a large link for "McAfee Virus Removal Services". Described as "McAfee Virus Removal Service detects and eliminates viruses, Trojans, spyware and other malware from your PC easily and quickly in the comfort of your home" for the low low price of $89.95.
So we'll try to lure you in with free software. In this case Adobe is complicit. And then after we find some sort of issue we will try to get $89.95 out of you because you don't know any better.
Needless to say, I've removed this software because I already have antivirus software running on my computer. There is an option to uninstall in the Programs menu.
I will be more diligent when downloading from Adobe in the future.
Sunday, June 19, 2011
Thursday, June 9, 2011
Exchange 2010 Management Tools Not Working
We recently took over support for an SBS 2011 server that is having issues (to put it politely). Our first indication that we have a problem was the Exchange Management Console and Exchange Management Shell not running properly. When EMC or EMS started, we'd get the following error.
The exchange online help indicated that this can be cause by a user not having remote powershell permissions. The EMC and EMS in Exchange 2010 use remote powershell which requires WinRM to be properly functional. The exchange help suggests running set-user userid -PowerShellEnabled $true. However, you can't without the EMS properly loaded. Following several documents, I attempted to verify that WinRM was properly configured and ran both Enable-PSRemoting and WinRM quickconfig with no fix.
Then I tried accessing just the main server web site at http://127.0.0.1 and found the following error.
This needs to be fixed because the EMC and EMS find WinRM by accessing the /PowerShell application in the Default Web Site.
After doing some more research I found that this is often a result of IIS not being properly configured. For Exchange 2010 CAS servers you should not enable 32-bit code. It should be 64-bit only. If you enable 32-bit code then you need to edit the applicationhost.config file and add the option preCondition="bitness64" in several lines for 64-bit DLLs that need to be loaded. This may be rewritten when you apply Exchange 2010 updates and is not recommended or required for Exchange. I made sure that 64-bit only was enabled by running cscript.exe C:\Inetpub\AdminScripts\adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 FALSE.
What finally got IIS functional again is copying extrace.dll from the Exchange bin folder to C:\Windows\System32. For some reason, this allowed IIS to find it and consequently load owaauth.dll properly.
At this point, the Application log showed a WinRM error for an Exchange as follows:
After doing a quick bit of searching, it turns out that this is a result of the variable %ExchangeInstallPath% not being defined on the server. Defining a System variable ExchangeInstallPath with a value of C:\Program Files\Microsoft\Exchange Server\V14\ fixed it up.
Some links I found useful when troubleshooting this issue:
Connecting to remote server failed with the following error message: The WinRM client cannot process the request. It cannot determine the content type of the HTTP response from the destination computer. The content type is absent or invalid. For more information, see the about_Remote_Troubleshooting Help topic.
The exchange online help indicated that this can be cause by a user not having remote powershell permissions. The EMC and EMS in Exchange 2010 use remote powershell which requires WinRM to be properly functional. The exchange help suggests running set-user userid -PowerShellEnabled $true. However, you can't without the EMS properly loaded. Following several documents, I attempted to verify that WinRM was properly configured and ran both Enable-PSRemoting and WinRM quickconfig with no fix.
Then I tried accessing just the main server web site at http://127.0.0.1 and found the following error.
HTTP Error 500 - Internal Server Error Calling LoadLibraryEx on ISAPI filter "C:\Program Files\Microsoft\Exchange Server\ClientAccess\owa\auth\owaauth.dll"
Error code: 0x8007007e
This needs to be fixed because the EMC and EMS find WinRM by accessing the /PowerShell application in the Default Web Site.
After doing some more research I found that this is often a result of IIS not being properly configured. For Exchange 2010 CAS servers you should not enable 32-bit code. It should be 64-bit only. If you enable 32-bit code then you need to edit the applicationhost.config file and add the option preCondition="bitness64" in several lines for 64-bit DLLs that need to be loaded. This may be rewritten when you apply Exchange 2010 updates and is not recommended or required for Exchange. I made sure that 64-bit only was enabled by running cscript.exe C:\Inetpub\AdminScripts\adsutil.vbs set W3SVC/AppPools/Enable32BitAppOnWin64 FALSE.
What finally got IIS functional again is copying extrace.dll from the Exchange bin folder to C:\Windows\System32. For some reason, this allowed IIS to find it and consequently load owaauth.dll properly.
At this point, the Application log showed a WinRM error for an Exchange as follows:
Request processing failed because the WinRM service cannot load data or event source: DLL="%ExchangeInstallPath%Bin\Microsoft.Exchange.AuthorizationPlugin.dll"
After doing a quick bit of searching, it turns out that this is a result of the variable %ExchangeInstallPath% not being defined on the server. Defining a System variable ExchangeInstallPath with a value of C:\Program Files\Microsoft\Exchange Server\V14\ fixed it up.
Some links I found useful when troubleshooting this issue:
- http://blogs.technet.com/b/exchange/archive/2010/02/04/3409289.aspx
- http://social.technet.microsoft.com/Forums/en-US/exchange2010/thread/5b82f131-b469-4661-9d6c-1c1c7939b73a/
- http://blog.misthos.com/2009_09_01_archive.html
- http://social.technet.microsoft.com/Forums/en-US/exchangesvrclients/thread/8b18c94b-5c2a-48ad-8ac0-06de12463f6b/
Tuesday, June 7, 2011
When Do You Need the Enterprise Edition of Exchange 2010?
I've run into a lot of confusion lately about when you need to Enterprise versions of Windows Server 2008 and Exchange 2010. It's actually very straightforward to decide. You need to ask two questions:
The only difference between Exchange 2010 Standard edition and Exchange 2010 Enterprise edition is the number of databases supported on each Mailbox server. There are no other differences. Database physical size is unlimited for both versions. DAGs are also supported on both versions.
A DAG requires the failover clustering feature that is only available in the Enterprise edition of Windows Server 2008. Failover clustering is configured and managed by the Exchange management tools, but it needs to be there.
It's worth noting from a design perspective that if you have a DAG and at least three copies of the database, then you can consider going backupless. In which case, you will likely use fewer large databases. Consequently, you often do not need the Enterprise version of Exchange Server building a DAG.
There is also an Enterprise Client Access License (CAL) for Exchange 2010. This CAL is required for all users accessing premium features. This includes unified messaging, the new personal archive feature, per mailbox journaling, and a number of other things. The Exchange Management Console identifies features that require an Enterprise CAL. A reference is here:
Finally the new retention policies and personal archives require not only Outlook 2010, but specific versions of Outlook 2010. Retention policies are implemented on the server side, but user tagging is unavailable with the incorrect version. Personal archives are visible only in the correct version of Outlook 2010. A version reference is here:
- Will there be more than 5 databases on a Mailbox server? If yes, you need Exchange 2010 Enterprise edition.
- Will you have a database availability group (DAG)? If yes, then you need Windows Server 2008 Enterprise edition for each Mailbox server in the DAG.
The only difference between Exchange 2010 Standard edition and Exchange 2010 Enterprise edition is the number of databases supported on each Mailbox server. There are no other differences. Database physical size is unlimited for both versions. DAGs are also supported on both versions.
A DAG requires the failover clustering feature that is only available in the Enterprise edition of Windows Server 2008. Failover clustering is configured and managed by the Exchange management tools, but it needs to be there.
It's worth noting from a design perspective that if you have a DAG and at least three copies of the database, then you can consider going backupless. In which case, you will likely use fewer large databases. Consequently, you often do not need the Enterprise version of Exchange Server building a DAG.
There is also an Enterprise Client Access License (CAL) for Exchange 2010. This CAL is required for all users accessing premium features. This includes unified messaging, the new personal archive feature, per mailbox journaling, and a number of other things. The Exchange Management Console identifies features that require an Enterprise CAL. A reference is here:
Finally the new retention policies and personal archives require not only Outlook 2010, but specific versions of Outlook 2010. Retention policies are implemented on the server side, but user tagging is unavailable with the incorrect version. Personal archives are visible only in the correct version of Outlook 2010. A version reference is here:
Exchange 2010 Server Not Added to Exchange Server Security Group
During the installation of Exchange 2010, the computer account for the Exchange Server is added to the Exchange Server security group. This ensures that Exchange 2010 on that server has access to any necessary information in Active Directory.
In most cases, computer names are unique between domains. However, if the computer that Exchange 2010 is being installed onto has the same computer name as a computer in another domain in the forest, the process of adding the new Exchange 2010 server to the Exchange Servers security group fails and the installation of Exchange 2010 fails.
This error occurs based on an Active Directory search for the computer name. So, the computer account with the conflicting name may be left over from a long time ago.
Easy solution, if the conflicting computer account is no longer required, then remove it. If the conflicting computer account is required, then rename your server before installing Exchange Server 2010.
In most cases, computer names are unique between domains. However, if the computer that Exchange 2010 is being installed onto has the same computer name as a computer in another domain in the forest, the process of adding the new Exchange 2010 server to the Exchange Servers security group fails and the installation of Exchange 2010 fails.
This error occurs based on an Active Directory search for the computer name. So, the computer account with the conflicting name may be left over from a long time ago.
Easy solution, if the conflicting computer account is no longer required, then remove it. If the conflicting computer account is required, then rename your server before installing Exchange Server 2010.
Wednesday, June 1, 2011
Unable to Delete Exchange 2003 Mailbox Store
Several times during Exchange 2003 to Exchange 2010 migrations, we've run into an issue where we are unable to delete the last mailbox store before uninstalling Exchange 2003. We receive a message like:
The easiest way to identify the user accounts with references to this database is by using a query in Active Directory Users and Computers. Create a custom query and enter in the following LDAP syntax:
After you identify the users with invalid references, you need to remove the references. In some cases, you can delete the mailbox from the user in Active Directory Users and Computers. Other times, you need to remove Exchange attributes from the user.
After you have cleaned up the Exchange information in the user accounts identified by your query, you should be able to delete the mailbox store and complete removing Exchange 2003.
One or more users currently use this mailbox store. These users must be moved to a different mailbox store or be mail disabled before deleting this store.However, when we use System Manager to view the list of mailboxes, only system mailboxes are displayed. The system mailboxes do not need to be deleted before the mailbox store can be removed. There are references to the mailbox database in Active Directory that may or may not be valid.
ID no: c1034a7f
Exchange System Manager
The easiest way to identify the user accounts with references to this database is by using a query in Active Directory Users and Computers. Create a custom query and enter in the following LDAP syntax:
(&(mailnickname=*)(msExchHomeServerName=*OldServerName*))This query search identifies mailboxes hosted on OldServerName. Since we are down to a single mailbox database on that server, it is unique enough to get us the information we need. Microsoft also has a list of other methods at http://support.microsoft.com/kb/279202/en-us.
After you identify the users with invalid references, you need to remove the references. In some cases, you can delete the mailbox from the user in Active Directory Users and Computers. Other times, you need to remove Exchange attributes from the user.
After you have cleaned up the Exchange information in the user accounts identified by your query, you should be able to delete the mailbox store and complete removing Exchange 2003.
Subscribe to:
Posts (Atom)