Tuesday, March 1, 2011

Lessons learned and pitfalls to avoid during SharePoint 2010 extranet architecture design

After we upgraded our SharePoint 2007 to 2010 in August 2010, we were very aggressive to implement SharePoint extranet based on the latest technology Microsoft provided. However, there are several majors issues found that has changed our design several times. As a result, our SharePoint 2010 extranet scheduled has been dramatically impacted. This post will listed the lessons we learned so you could avoid some pitfalls during your extranet implementation.

  1. First lesson is you should not be optimistic and greedy on Microsoft latest SharePoint technologies for extranet implementation. During extranet implementation, ADFS was brought to our attention and it seems like an excellent solution for internal and external SharePoint. We have spend almost two months to successfully setup the ADFS and convert all window based authentication to ADFS claim based authentication on a non production environment. However, we have identified dozen major issues that some of the out of box SharePoint functions will not work as it is. There is no clear roadmap from Microsoft to clear identify the roadmap to resolve those. One example is audience targeting is no longer working based on usersSeveral services need C2WTS services to work. BCS can not use C2WTS service and you could not setup BDC through designer. Of cause, we have identified workaround on some of  the issues identified that will be posted in the near future. Another information you should know is ADFS 2.0 is NOT supported for ForeFront UAG at this time. You have to dowgrade ADFS to 1.0 if you plan to use UAG now. Based on Microsoft insider that it should be supported around September 2011.
  2.  Second lesson is you should pay extra attention connections and ports used between SharePoint each servers and contact your security and network team to evaluate the Microsoft extranet topology before final architecture design. We had originally evaluated both Split back-to-back optimization for content publishing and edge firewall architecture. It seems the first one make sense not pay additional license for Forefront UAG license. However, if you looked at the Microsoft extranet topology, the notes are sending us to the discussion with corporate security and network teams. The significant note is it requires a one-way trust relationship in which the perimeter domain trusts the corporate domain.  This immediately brought attention from the security team since this is not allowed in our company policy.In additional, the front servers in DMZ also need to connect to internal AD for internal users and SQL server for search crawling! There will be multiple ports need to opened besides the one-way domain trust. You should check with your security team on the policy and avoid such pitfall.
  3. Third lesson is you would need to double check the cost of the extranet implementation based on different architecture. At beginning, we did not select edge firewall architecture since it will require Forefront UAG license and Forefront UAG SharePoint extranet adapter license in additional to WFE extranet adapter and SQL extranet license. You will need to check cost if you need additional servers and any third party server based license cost.
Well, after all these discussions, we are back to the edge firewall architecture and is working with finance team to approve the additional cost needed for the hardware and software.

Please check back to see our progress and good luck with you implementation.

2 comments:

  1. Hi Harry, great post. Can you update the status of your extranet implementation? Are there any other issues you experience with the implementation?

    ReplyDelete
  2. Been awhile but howd it all tufn out?

    ReplyDelete