Posts Tagged ‘Web site design’

SharePoint FIS and SharePoint FIS Licensing: Usage Scenarios (Part 2 of 2)

February 19th, 2012
Posted by: admin

By Bill Peters
AIS Network Director of Sales

In my January 24 blog, I provided some responses to frequently asked questions about Microsoft SharePoint Server 2010 for Internet Sites and licensing SharePoint FIS.

In this second part, we’ll look at SharePoint FIS licensing in a little more depth and also look at some various usage scenarios.*  For the purposes of this blog, “internal users” refers to employees, affiliates’ employees, on-site contractors and/or agents.  “External users” refers to all others.

What do I need for intranet and extranet sites?

For intranet and extranet networks used to support internal content, SharePoint Server 2010 is required.  If only internal users can access the content being stored, it must be hosted on a server licensed with SharePoint Server 2010.  It’s important to remember that content is only accessible by users or devices with a Client Access License (CAL) for SharePoint Server 2010.  SharePoint Server can still be used to support external content, although each user or device requires a CAL, whether they are internal or external.

What do I need for Internet sites?

For servers used to provide external content (typically) over the Internet, SharePoint FIS is required.  If the content being stored and accessed is available to external users, it can be hosted on a server licensed with SharePoint FIS, and users accessing that content will not require a CAL.  It’s important to remember that while SharePoint FIS is restricted to external content, it is not restricted to external users.  For example, an internal user (e.g., employee) would not require a CAL to access external content on an instance of SharePoint FIS.  As you can see, the choice between SharePoint Server and SharePoint FIS for external content is a financial one, unless the external users have anonymous access—in which case, SharePoint FIS is the only feasible option.

Can you show me some usage scenarios?

The following common deployment scenarios are excerpted from a very useful and detailed document entitled, “Microsoft Volume Licensing Brief:  Microsoft SharePoint Server 2010 for Internet Sites” (October 2010), which helps in explaining the licensing requirements of SharePoint FIS.  Although covered for user-based CALs, these scenarios can also be used for device-based CALs.  For a copy of the full document, just email me at the address below.

First, have a look at the color code for the diagrams:

SharePoint 2010

Color code for diagrams. Source: Microsoft Volume Licensing

SCENARIO A:  Intranet

Description: Internal users access information through LAN or the Internet. No other users (internal or external) have access to information or applications.

Example: A professional sports team sets up an intranet site accessed by managers, the coach, and players.  It is also used for support staff such as the physiotherapist who is an on-site contractor rather than an employee.  But the therapist still qualifies as an internal user.  A news reporter trying to access the SharePoint site is denied access.

Licensing:

  • Server — 1 SPS/Running Instance (RI)
  • Internal User — 1 CAL/User

Figure 1 – Scenario:  Intranet

SharePoint 2010 Sports Team Scenario

Source: Microsoft Volume Licensing

Key Takeaway:

  • Licensing requirements for server and CAL remain the same for internal users based on the location of access (through LAN or the Internet).

 

SCENARIO B:  Intranet Plus Extranet

Description: An organization with information accessible only by internal users (i.e., internal content) chooses to extend access to a limited number of identifiable external users.  In this case, the identifiable external users have access to all information, previously accessible by internal users only.   The organization may choose to license those external users either via SPS/CAL or SPSFIS for authenticated external users.  This decision is typically made based on cost.

Example:  The Elm University publishes research papers, which are made available to specific educators from other universities (external users).  This situation is assumed to be an intranet plus extranet scenario, even though the Elm University does not have a public-facing Web site.

Licensing:

  • Server — 1 SPS/RI
  • Internal User — 1 CAL/User
  • External User — 1 CAL/User

-or-

  • Server — 1 SPS/RI (for internal use), 1 SPSFIS/RI* (for external use)
  • Internal User — 1 CAL/User
  • External User:  No additional licenses required.

SPS/CAL Only

Figure 2A – Scenario:  Intranet Plus Extranet Without SPSFIS

SharePoint 2010 Elm University Scenario A

Source: Microsoft Volume Licensing

SPS/CAL Plus SPSFIS

Figure 2B – Scenario:  Intranet Plus Extranet with FIS

SharePoint 2010 Elm University Scenario B

Source: Microsoft Volume Licensing

Key Takeaways:

  • You can choose between SPS/CAL or SPSFIS based on what is more economical to them given the number of external users.
  • The licensing requirement for internal user varies depending on the server license chosen and use (publishing or internal use of information/applications).
  • The university chooses to make external content available to selective external users.  With SPSFIS licensing, no restriction is made on how many external users access that information.

SCENARIO C:   Internet

Description: Internal users are publishing information for external users.  It is not possible to identify some or all of external users, so you must license external users via SPSFIS.  Because internal users access the same information as external users, all users can be licensed via SPSFIS, and no additional CALs are required.

In another example, a team of internal users is customizing the look and feel of the Web site and testing it before the changes go live in production; CALs are not required if the internal users have MSDN licenses.

Example: News Web site, knowledge forums, and social networking sites

Licensing:

  • Server — 1 SPSFIS/RI
  • Internal User — Need no CAL
  • External User — Need No CAL
  • Test/Dev: If users are covered via MSDN, no additional server licenses/CALs are required.

Figure 3 – Scenario:  Internet

SharePoint 2010 Newspaper Publishing Scenario

Source: Microsoft Volume Licensing

Key Takeaways:

  • SPSFIS/RI is the only license required if internal users are accessing the same sites as external users.
  • Each staging server that is posting content requires its own SPSFIS/RI (same licensing requirement as production server).  This requirement excludes test staging servers because testing technical changes are covered under MSDN.

SCENARIO D:  Intranet Plus Internet

Description: You make some content available only to internal users, while other content is made available to anonymous external users.

You need one SPS/RI for the internal content, one CAL/user for all internal users accessing that internal content, and one SPSFIS/RI for the external content accessed by anonymous external users.  SPSFIS negates the need for CALs for internal users only publishing information and all external users.

Example: Woodgrove Bank offers loan information and the option to submit a loan application on its public-facing site, on which only internal users are allowed to view/work.

Licensing

  • Server — 1 SPS/RI for servers for internal information, 1 SPSFIS/RI* for servers for external information
  • Internal User (if only publishing) — needs no CAL
  • Internal User (otherwise) — 1 CAL/User
  • External User — needs no CAL

Figure 4 – Scenario:  Intranet Plus Internet

SharePoint 2010 Bank Scenario

Source: Microsoft Volume Licensing

Key Takeaways:

  • If internal users are only publishing information and SPSFIS/RI is being used for the servers, CALs are not required for them.
  • If the contents/information/applications accessed by internal users are different from those accessed by external users, SPS/CAL licenses are required for internal users.

SCENARIO E:   Intranet Plus Internet Plus Extranet

Description: In this scenario, one subset of information is available only to internal users, another subset of information is available to both internal users and authenticated external users, and a third subset of  information is available to anonymous external users.

Example: Contoso Pharmaceutials maintains a public Web site accessible by all, offers collaboration with authenticated external users on specific research and development  projects, and hosts company’s internal intranet for its internal users.

Licensing:

  • Server — 1 SPS/RI for servers for internal information, 1 SPSFIS/RI for servers for external information*
  • Internal User (publishing) — needs no CAL
  • Internal User (otherwise) — 1 CAL/User, External User à needs no CAL
  • External User —  needs no CAL

*In the case of dedicated server for extranet, users would have a choice of SPSFIS to cover all authenticated external users or extending CALs to them, as discussed in Scenario 2.

Figure 5 – Scenario:  Intranet Plus Internet Plus Extranet

SharePoint 2010 Pharmaceutical Company Scenario

Source: Microsoft Volume Licensing

Key Takeaways:

  • This scenario shows that the Internet plus intranet plus extranet scenario is no different than the sum of the individual scenarios.
  • An organization can choose to make external information available to selective external users. However, with SPSFIS licensing, no licensing restriction is made on how many external users can access external information.

This is so confusing.  Isn’t there someone who can help me figure this out?

Yes, as I mentioned in January, if you think SharePoint FIS licensing is confusing, you are not alone.  I’m happy to walk you through it and help you assess your organization’s needs.

Call me at 1-888-401-AISN, or email me at:  bill.peters@aisn.net.  Or, simply leave a comment below.  Best of luck!

 

 

TAGS:

CATEGORIES:

9 Comments »

Web Design and Development: Best Practices in Production, Staging and Development for Web-Based Companies

December 12th, 2011
Posted by: admin

GUEST BLOG

By Gaige B. Paulsen
Board of Advisors, AIS Network

For companies that primarily do business through their public-facing Internet site, best practices for production, staging and development are imperative.  For any Web-based business, whether e-commerce or presence-based, it is essential that content and systems be updated to remain competitive, which means change and that means risk.

Web-based businesses wrestle with complexity on a daily basis.  Typically, there are multiple developers involved, different development timelines, and numerous components being built simultaneously, tiered systems to synchronize for updates, etc.  One misstep in the development and deployment cycle has the potential to cost the business millions of dollars.

In my various capacities, I have spent years refining best practices for production, staging and development environments.  Normal best practices these days are for the following:

  • A serious version control system (VCS) or distributed version control system (DVCS).  Depending on the architecture, I’m still using   Perforce, which is expensive, but über-reliable.  Many folks like GIT, Subversion, and Mercurial.
  • Serious issue management to track platform development and bug fixes/handle actionable team communication, etc. I recommend   JIRA.
  • Development environments that run on developers’ personal machines in a sandbox or VM, or if substantially small in terms of the number of processes, just in the OS (if they’re running desktop/laptop Linux).   Development environments should be a little version of production.
  • New development that is branched in the VCS and not let into the mainline branch until complete.   Branches can be team-centered or developer-centered depending on how many developers are working on the particular piece of code.   But a modern VCS makes it easy to branch early and merge back in only when development is complete.
  • Staging is essential and should be gate-kept.  Development should be promoted to staging through the VCS.   This way, the act of promotion provides a dry-run for the move from stage to production.
  • Scripted tests for Web-based platforms.   I suggest looking at   Sauce Labs for this, or roll-your-own using   Selenium.
  1. Staging is generally used as a dry run for a move to production and final testing.   Nothing should go to production that doesn’t succeed in stage.
  2. Stage should have a lazy copy of the entire environment if possible (full user base, etc.), but shouldn’t directly touch anything that could cause user confusion (sending email to users, etc.).   It can be quite difficult to get a reliable stage environment set up, especially if you need multiple servers to do it (DB, File, GUI, etc.).   But, the more complex the real environment, the more complex the stage environment and the more important it is to get staging working correctly.
  3. Stage is also where you perform human testing on things that can’t be scripted.   There shouldn’t be need for a lot of this on a Web app, but there are some things that are hard to do in an automated fashion (i.e., does the site look “bad”?).
  • Unit tests for internal functionality need to be baked into the development process.   High-volume organizations tend to make automated running of the 3 major test types (integration, unit, and scripted GUI). As a safeguard, a trigger in the check-in process is important so that code that violates testing cannot be checked into the code base at all and instead remains on the developer’s machine.
  • If you can do it, Continuous Integration is a boon to keep things from getting too far afield.  Code compilations, environment synchronization, and spawning automated testing when checks occur are all great tools and can be done very inexpensively with   Jenkins.
  • Work on production is considered to be a complete fail.   The only reason to do it is catastrophic failure of something that does not happen in the stage and development environments and is a sign that the stage is an inadequate representation of production.   Usually, this would only be to change configuration parameters.
  1. If production breaks roll back to the previous version of the site.   If that fails, then you have no choice but to work on production.
  2. Note that even for catastrophic situations, changing code directly on the production servers is just as likely to make things worse if they haven’t passed the rest of the testing in stage.
  • You can do a lot of debugging on the production site, where debugging is gathering information about something that isn’t working correctly.   You shouldn’t, however, use the production site as a test bed or development environment.
  • If your tests don’t do things that you wouldn’t want done in the production environment (adding and removing users and files, changing parameters, simulating failures, etc.), then you don’t have sufficiently detailed tests.

This is the tip of the iceberg, but before anybody tells you that these methods are too overbearing for a small team, I would suggest that’s a short-sighted view.

At my company, we practice this in a team of small developers for mobile, desktop, and Web apps.   The result is that, in over two years, we have not suffered data loss or corruption in the Web site, which handles our registration, e-commerce, etc. Additionally, we have caught many things that would have been problematic for users if they’d been released.  Similarly, regression testing in mobile and desktop apps had kept us from releasing versions of the software that don’t work on all of the supported platforms and has saved us a lot of customer difficulties.

I hope this is helpful, and I invite you to comment.  Good luck.

Gaige B. Paulsen is a technologist and entrepreneur.  He is currently founder and president of ClueTrust, makers of Cartographica and CartoMobile, Geospatial products for MacOS X and iOS.

TAGS:

CATEGORIES:

2 Comments »