This is my first post so I thought to start with a strange case that I was working on last week.

Customer environment as follows:

- Exchange 2010, with CAS configured properly for Outlook Anywhere.

- TMG configured to publish Outlook Anywhere.

Problem Symptoms:

- Outlook Anywhere on Windows 7 is working fine.

- Outlook Anywhere on Windows XP with SP3 is not working for both Office 2003 and Office 2007.

If configuring Outlook for the first time it will hang after asking for the user name and the password, same if Outlook configured before, once opened it will ask for the user name and password and then not responding.

Troubleshooting:

Testing from Windows 7 proofs that the configuration is ok, also testing Outlook Anywhere from Internet Explorer is working fine (https://mail.customer.com/rpc/rpcproxy.dll).

The key in identifying the problem was testing XP from the internal network and everything worked fine, then it should be something in TMG publishing rule.

Solution:

on the first look the rule looks fine, and also is working from IE and Windows 7, checking the rule on the second time and check the following snapshot:

The Load balance Mechanism first was selected to be “Cookie Based”, of course Outlook Anywhere should be configured as Source IP, once changed to the right configuration as the snapshot above everything now is working fine.

My conclusion for that strange behavior that Outlook 2003 and 2007 not supporting any cookies (only Outlook 2010 supports “Outlook Session” Cookie), it seems that Windows 7 is smart enough so it’s dropping the cookie and ignore it, for XP it can’t understand the cookie and Outlook hang with no response.

• If you are trying to reproduce unique virtual machines, always check the generalize checkbox (or use SYSPREP /generalize) to make sure the machine gets a new SID, NIC GUIDs and other identifiers, if you don't, your AD DS will have the impression that you have two of the same machine (since it identifies machines by SIDs) and the situation can get messy. Nonetheless, some features like Windows Network Load Balancing can get confused since multiple NICs have the same GUID.
• SYSPREP can only reset the Product Activation Key 3 times.
• Use the sysprep /oobe (which refers to the Out Of the Box Experience), to allow for the customization for Windows settings after the reboot
• Do not use SYSPREP on Upgrade versions of Windows, use it only for clean installations, the SYSPREP version of each installation of Windows could be different and this can cause trouble
• Before you SYSPREP a virtual machine, always make sure you are NOT running the CLI for SYSPREP on the Hyper-V host rather than the virtual machine itself :) it happened to me once, but thank God it was in my own testing lab. 

Furthermore, this is a table that includes the roles that are supported for SYSPREP.  If you have to SYSPREP a machine that is intended to host a certain unsupported role, SYSPREP it before the role is installed.

Sometimes you need to build bulk query to select, update or insert data to SQL tables. The selected, updated or inserted data is dynamic and is selected based on data in many tables.

An example of this is the following requirement:

•       For each row in a table that belongs to a GUID related to a specific condition in another table, we want to insert another row with specific values.

Note that the number of Insert SQL statements needed can be high based on the initial condition.

To achieve this requirement, there are three options:

•       Manually create queries
•       Pros: Most efficient if low number of rows
•      Cons: Not suitable for large number of rows or complex conditions
•       Create a Utility using .Net Framework
•       Reads Data from SQL Servers
•       Applies commands to add/update/delete data
•       Pros: Can be very flexible to apply changes directly or saving script files
•       Cons: Time Consuming, Performance is not optimized
•       Writing Queries on SQL Server that creates queries for insert/update/delete
•       Pros: Simple Syntax, Optimized Performance
•       Cons: Not very intuitive when the complexity of the conditions for the query is high.

Generally, each of these methods has its pros and cons so there is no solution that fits all; however, SQL Queries usually gives the best performance with medium complexity.

In my next post, I’ll give some examples on the use of SQL Queries to create queries to insert/update/delete to demonstrate its power in achieving many such scenarios.

While doing custom development on SharePoint using Visual Studio, it is common to get "The security validation for this page is invalid". I give 2 simple steps to troubleshoot this issue, I assume that you did not yet go into playing with the Web Application security settings (And please do not!!)...

Step 1: In the master page, ensure that the Form Digest control is there, put it at the end of your master page. This should look like ...

<asp:ContentPlaceHolder id=”PlaceHolderFormDigest” runat=”server”>
        <SharePoint:FormDigest runat=”server”/>
</asp:ContentPlaceHolder>

Refer to this MSDN article: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.webcontrols.formdigest.aspx

Step 2: Your code might be running with Elevated privilege using SPSecurity.RunWithElevatedPrivileges. If your code is performing updates to the web application, you will get this security error or "Access Denied" error. To avoid this, use the SPUtility.ValidateFormDigest() before running your elevated code. This should be something like...

SPUtility.ValidateFormDigest();
SPSecurity.RunWithElevatedPrivileges(delegate()
{....

 Refer to this MSDN article: http://msdn.microsoft.com/en-us/library/microsoft.sharepoint.utilities.sputility.validateformdigest.aspx

What not to do:

Never, Never, play with the Farm or WebApplication security settings. I have seen many blogs that will ask you to web.AllowUnsafeUpdates=true; or ValidateFormDigest.Enabled=false; if you do this, you open security threats to your web application. People can submit incorrect data and bypass ASP .Net security. When trouble happens or you web site is attacked, it should not be your code to blame.

Happy coding:)

On March 29^th we posted an announcement to the EHLO blog about removing Update Rollup 3 for Exchange Server 2007 SP3 due to an issue that could result in database corruption.

The Exchange Servicing team has fixed the reported issue with RU3 and is making available a new version of RU3 for our customers, version 08.03.159.002, (KB2530488). We strongly advise all customers install this newly released version of Microsoft Exchange Server 2007 SP3 Update Rollup 3 and to discard any prior version of RU3 (KB2492691) which you may have.

RU3 Installation Guidance:

• Customers with RU3 already installed within your Exchange environment

  It is not necessary for you to uninstall the existing RU3 within your environment. The new RU3 package can be installed over the top of the existing package installed on your servers.

• Customers with previous SP3 RU’s installed within your Exchange environment

  You can simply install the new version of the RU3 package.

General RU Installation Guidance

• Note for deployments that leverage Forefront Security for Exchange: For those of you running Forefront Security for Exchange perform these important steps from the command line in the Forefront directory before and after this rollup's installation. Without these steps, Exchange services for Information Store and Transport will not start back up. You will need to disable Forefront via "fscutility /disable" before installing the patch and then re-enable after the patch by running "fscutility /enable" to start it up again post installation.

We deeply regret the impact that these issues have had on our customers, and as always, we continue to identify ways to better serve your needs through our regular servicing releases.