Marc Lognoul's IT Infrastructure Blog

Cloudy with a Chance of On-Prem


UAG2010: Configuration Lost after Installing Service Pack 4

ForeFront UAG

Introduction

In this post I will modestly relay a problem experienced by a customer that was hopefully resolved by MS product Support.

After Installing the Service Pack 4 of UAG 2010, the complete configuration was missing. It was impossible to restore a backup taken prior installing the Service Pack because the schema of the database storing the configuration evolved. We were in a rather uncomfortable position…

Solution

Hopefully, the solution to this problem is rather simple:

  1. From the Control Panel, uninstall the Service Pack 4 and reboot once prompted
  2. After rebooting, open the UAG console and verify the current build version of the product. Due to the prerequisites for SP4 installation, it should be 4.0.3206.10100, which means Service Pack 3 + Update Rollup 1. You can refer to this page if you need MS product build versions, it covers UAG2010 as well
  3. “Normally”, the configuration should be back as well. If not, restore it from a previous backup. Since build versions are identical, it should work fine
  4. Activate the configuration then reboot the server again. The situation should be stable from this point. For safety, take a new backup before going any further
  5. From now you can attempt to install the Service Pack 4 again
  6. After successful installation, activate the configuration again and take a backup

Proactive Action

In order to prevent this problem from occurring on other Service Pack 4 deployments, proceed as follows:

  1. Make sure Service Pack 3 and Update Roll-up 1 are installed
  2. Activate the configuration with the current build level
  3. Reboot the server
  4. Take a backup
  5. Deploy Service Pack 4


SharePoint 2013: Stretched Farm vs. Real Life vs. Supportability

Introduction

SharePoint Server MVP Serge Luca has recently written a very interesting article over stretched farm and their supportability boundaries in SharePoint 2013: Stretched farms and SharePoint 2013: what I don’t understand.

While the article itself is very well written, I don’t necessarily agree with him and wanted to partially share my opinion here. Later I will try to publish another post debunking stretched farm HA/DRP “facts”.

The Fear of the “Not Supported”

Obviously, it is safer to respect supportability rules set by Microsoft (or any vendor). However, other factors should be taken into account when architecting a solution and evaluating its “supportability”:

  • (Microsoft) Supportability rules are continuously changing. If you look at the whole life-cycle of a product or service, you’ll see that many aspects of its supportability have evolved, most of time in favor of the customer’s needs. In Microsoft terms, “Not supported” may often means “not (enough) tested to be sure/safe” and with product adoption getting broader and customer providing feedback to MS, supportability becomes more and more flexible.
  • Not complying with one or multiple supportability rule(s) does not (necessarily) imply not being supported at all. I have rarely (not to say never) seen a case supportability was seen as a whole. As a matter of fact, fixing an orphan in a content database using direct SQL access will be allowed by MS Support regardless of the bandwidth and latency conditions unless they prevent correct execution. They will never be measure upfront
  • Use your TAM as a mean to provide feedback to MS and to gain more flexibility from the Support Teams. Getting extra room from the support is also a matter of influence, particularly for larger customer. Solving a case dealing with supportability limits can be perceived as a challenge for support engineers. It can certainly be used to build the case of supportability rule extension or improvement. If you (customers), don’t make yourself heard to MS, MS will obviously never hear you
  • Finally, even under very difficult circumstances in which multiple rules were broken, I have seen support engineers working day and night to solve an incident. While MS calls this “best effort”, it might sometimes be as good as standard-scoped resolution

That said, I am not trying to convince customers to do whatever fancies them with SharePoint regardless of the most basic care but in and ever-changing IT world, architecture or design should not be too restricted due to generic support conditions that will, anyway, evolve over time. More over Customers and consultants should be the initiator or contributor to that evolution.

So, About the Network Requirements, Realistic or Not?

Serge’s first assertion: It is not realistic to meet the 2 fundamental requirements

From the TechNet Article:

  • There is a highly consistent intra-farm latency of <1ms one way, 99.9% of the time over a period of ten minutes. (Intra-farm latency is commonly defined as the latency between the front-end web servers and the database servers.)
  • The bandwidth speed must be at least 1 gigabit per second

Obviously, if you “simply” plug SharePoint to you network and hope the requirements above will be met by chance or accident, or course, they won’t be. One of the toughest part of the job as SharePoint infrastructure specialist is to make sure all underlying components are meeting the requirement or are as close as possible to avoid any negative impact, not only for supportability reasons but mainly for customer satisfaction.

To meet the requirements, the network, H/W and the OS/Virtualization layers must be designed or at least adapted to support them:

  • Do not place SharePoint servers and SQL servers far from each other in term of subnets (one hop maximum)
  • Do not firewall server-to-server traffic, instead, firewall network(s) outside the SharePoint perimeter. If you care for segmentation, use layer 3 switching
  • Dedicate network pipes to SharePoint and SQL, enforce with QoS
  • Needless to say you need at least gigabit on the server’s NIC and much more on the switch(es) (10 Gb and more). Do not overcomit virtualized resources, as I often see
  • Systematically chase all issues preventing fluent network communications. And there are a lot (faulty NIC, Switch, out-of-date or incorrectly configured drivers, to name but a few…)
  • Finally, carefully measure and monitor both latency and bandwidth and observe their trends. Obviously don’t use ping or ping alike, use TCP-level probing at least

Assertion #2: Those requirements are not even met inside the same Datacenter

And that can often be true. Meanwhile it’s a question of defining what a “data center” really is. Are we talking in term of buildings, racks, IP network or anything else? Depending on who you talk to (facility manager, network architect or engineer, storage specialist, Windows or Active Directory consultant), each of them will have his/her own view about what is a data center.

In order to prevent this type of useless discussion, I simply recommend to wipe the concept of data center of the board and speak exclusively about how atomic a SharePoint farm must be. Regardless of their logically or physical location, SharePoint, SQL and other directly connected servers (DC, SSRS…) should meet the requirements in a consistent and persistent manner, at least during the business working periods as defined by the customer (this must match the SLA applied to each SharePoint service)

Assertion #3: OWA (read WAC actually!) has specific requirements

Just by reading the original TechNet Article, you can perceive that it may have been written by totally different people working on different products. Therefore even if at the end, the requirements are actually similar, they may look different “on paper”.

But once again, it is a matter of consultant and customer feedback and influence to align requirements and the way they are expressed by MS.

Conclusions

  • First, the purpose of this article is to explain my point of view on Stretched Farm Supportability’s requirements, not to bash Serge, let’s be clear!
  • Microsoft Support Services is not that monolithic thing . You can interact with them in a constructive way. Note: I am not getting any remuneration from MS by saying this, right?
  • Many aspects of SharePoint’s requirements are difficult to reach. Network is not the least but not the last either
  • Our job as consultant is to help the Customer undertanding MS’s views or plans not only as they are today but also in the coming weeks or months (let’s not speak about years, I drive no DeLorean). It does not necessarily mean accepting anything at any price
  • While I agree on the fact that the future of SharePoint is in the Cloud, there is for me no Relationship between farm topology, supportability and Cloud adoption
  • And finally, just like Captain Barbossa would say, TechNet Articles “are more what you’d call guidelines than actual rules” 🙂