locked
Maximum number of user supported by single enterprises pool RRS feed

  • Question

  •  

    Hi Can someone tell what is maximumm number of users supported by single enterprise pool. I am having single front end server and what if i add load bancer with one more server; will it increase the number of users supported by my environment.
    Wednesday, November 12, 2008 12:05 PM

Answers

  • The OCS 2007 Planning Guide lists the maximum supported users for each topology, check the Capacity Planning chapter:

    http://www.microsoft.com/downloads/details.aspx?familyid=723347c6-fa1f-44d8-a7fa-8974c3b596f4&displaylang=en

     

    A single Standard Edition server shows a maximum of 5000 supported users, while the Consolidated Enterprise Configuration lists 4 server nodes supporting 30,000 users.  Assuming that a single-node EE pool would support exactly 25% of that, then you'll get 7500 users.

     

    I'd guess that offloading the SQL processing to a back-end server accounts for the 2500 user difference between a single Standard and Enterprise front-end server.  So it appears that 5000-7500 users is your upper range.

     

    Wednesday, November 12, 2008 7:53 PM
    Moderator

All replies

  • The OCS 2007 Planning Guide lists the maximum supported users for each topology, check the Capacity Planning chapter:

    http://www.microsoft.com/downloads/details.aspx?familyid=723347c6-fa1f-44d8-a7fa-8974c3b596f4&displaylang=en

     

    A single Standard Edition server shows a maximum of 5000 supported users, while the Consolidated Enterprise Configuration lists 4 server nodes supporting 30,000 users.  Assuming that a single-node EE pool would support exactly 25% of that, then you'll get 7500 users.

     

    I'd guess that offloading the SQL processing to a back-end server accounts for the 2500 user difference between a single Standard and Enterprise front-end server.  So it appears that 5000-7500 users is your upper range.

     

    Wednesday, November 12, 2008 7:53 PM
    Moderator
  • First, the planning guide really shouldn't list a "maximum suported users" number at all. There is NO maximum number of users (beyond whatever maximum number of records Active Directory supports, anyway) for OCS users. There is no MAXIMUM number of users coded into any of the server roles.  In addition, these numbers do not represent "configured" users at all, but active, CONCURRENT users. Very different. And finally, the numbers are based on specific assumptions about hardware, user behaviour and other factors that can vary. Putting different hardware underneath, with different memory and CPU behaviour can change these numbers dramatically.

     

    So, just be aware that the numbers from the planning guide are really guidelines to the number of active, concurrent users that SHOULD be supported in a given topology type, based on a specific hardware platform, specific user behavior model, and specific workload and server configuration.

     

    Most of this is spelled out in the planning guide, though I acknowledge it isn't very clear. Here is a sample quote from page 76 of the Capacity planning guide:

     

    The following requirements are based on the following user model and assumes that each deployment supports IM, Web conferencing and audio-video and voice.

     

    In general, section 5, starting on page 73, discusses the assumptions beneath the supported user numbers listed in the various tables. The recommend hardware for an OCS front end server (either SE or EE) is NOT tied to a specific number of users. The hardware recomendations, deployment design (are all server roles deployed/in use), user configuration (how many users are enabled for which modalities, how many are enabled for outside user access, PIC, federation, etc), and usage patterns (how many users are active simultaneously at peak usage, how many conferences of a given sizse are ongoing, etc) are all related to the capacity to properly support a given number of uses.

     

    The base hardware config for an FE (either SE or EE) is given in the guide, but is easily and affordably exceeded with current server hardware:

     

    CPU

    Dual processor, dual core  2.6 GHz +

    Disk

    2 x 18 GB


    For collocated Standard Edition Server, add:

    2 x 36 GB, 15K RPM, RAID 0, for database log files

    2 x 36 GB, 15K RPM, RAID 0, for database data

     

    Cache

    1 MB L2 per core

    Memory

    2 GB  (4 GB for Standard Edition Server or Consolidated Enterprise Edition Server)

    Network

    GBit NIC

     

     

    • Proposed as answer by Duncan Blake Tuesday, March 3, 2009 3:48 AM
    Wednesday, December 10, 2008 8:52 AM
  • I'd like to expand on your statement as I think it could be misleading.  The numbers quoted in the Planning document are NOT concurrent-usage numbers.  You are correct in that they are not 'hard-coded' limits written into any single limiting component, but it's unlikely that a Standard Edition Server would support 5000 concurrent peer-to-peer video calls with IM (as a usage case example).  By 'concurrent use' they are talking about 'signed-in' users.  And in a typical environment I'd expect to see ~90% of users signed-in at the same time, but would NOT expect to have those same 90% having conferences and making voice calls at the same time.

    The sizing example (based on the documentation in the UC Voice Ignite materials which were also written by some of the same people that wrote the original deployment docs and Resource Kit book) typically averaged 5-10% concurrent use of Audio/Video/Telephony features. So a 5000 user maximum would assume ~375 concurrent connections (using 7.5% by splitting the difference). 

    The sizing is mostly sensitive to a mixture of hardware and feature use.  An IM/Presence-only deployment would certainly allow for higher numbers than a deployment using all multimedia features.
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Saturday, December 13, 2008 2:01 PM
    Moderator
  • Jeff, thanks for taking the time to expand on my comment.

    I think we have a small (but potentially important) disagreement on the proper understanding of "concurrent", as it is used in the context of the OCS planning guide, but I expect that we would essentially agree on the important take away from this discussion, which is that the key decision points between SE and EE is NOT the maximum number of users supported, but rather key feature requirements for a deployment, in the areas of high availability, scalability and performance. SE is intended for smaller organizations, departmental deployments, or projects such as pilot deployments that do not have high availability and scalable performance requirements.

    That said, I was perhaps not careful enough in my original response to emphasis that "concurrent users” meant "concurrently signed-in users", and that the "specific user behavior model" to which I referred included how many IM, audio, video, etc, sessions and conferences would be made per user, per hour, and what the average size and duration of those sessions would be.

    If there is any doubt about the fact that scalability numbers refer to "concurrent users", as opposed to a maximum number of users, some percentage of which would be concurrently signed in, I would refer interested parties to the TechNet Webcast on Capacity Planning for Office Communications Server 2007 presented by Byron Spurlock of Microsoft Consulting Services, in particular to the section around timestamp 6 minutes and 50 seconds, where he clarifies that "the 5000 users are active, concurrent, and not just logged into the system doing nothing, but actively using the system". He does NOT mean (and clarifies specifically to ensure we understand this) that all 5000 users are making calls or participating in AV conferences simultaneously, but that they are following the user behavior model behind the scalability and support recommendations.

    This is context in which I, respectfully, disagree with your contention that the "numbers quoted in the Planning document are NOT concurrent-usage numbers." They are, but within the specific hardware platform, user behavior model expectations, etc, on which the Planning guide recommendations are built.  

    For further context, I recommend the current OCS R2 documentation, which is still not entirely clear on this area, but offers considerably more detail about the user behavior model behind scalability and capacity planning recommendations.
     

    Some samples:

    Table 1. User Model for Office Communications Server
    Category  Description 
    Remote user distribution 90% of users connecting internally
      10% of users connecting through an Edge Server, and (recommended) a Director
    Contact distribution Average of 80 contacts on mobile devices
      Average of 50 contacts on all other devices
      70% of contacts within the organization
      10% of enterprize users are remote
      10% of contacts are federated
      10% of contacts are public IM contacts
    IM sessions 2 IM sessions/user/hour
      10 instant messages per session
      400 byte average message size
      Three-person average for multiparty IM sessions
    Table 2. Conference Model
    Category  Description 
    Scheduled meetings versus "Meet now" meetings 50% of each category.
    Meeting media distribution 15%: PSTN audio through a third-party audio conferencing provider, PowerPoint®.
      10%: PSTN audio through a third-party audio conferencing provider, application sharing.
      15%: Group IM with distribution group integration.
      10%: PSTN audio dial-in conferencing only.
      10%: VoIP audio, PSTN dial-in conferencing, PowerPoint.
      25%: VoIP audio, PSTN dial-in and video, application sharing.
      5%: VoIP audio, PSTN dial-in, IM, and application sharing.
      10%: VoIP audio, PSTN dial-in, video, IM.
    Meeting participant distribution In meetings where Conferencing Attendant is used with a combination of VoIP audio and PSTN dial-in audio, the ratio of VoIP users to dial-in users is 2:1.
       
      For application sharing, two types of application sharing exist: Persistent Shared Object Model (PSOM) based application sharing using the Web Conferencing Server and Remote Desktop Protocol (RDP) based application sharing based on the new Application Sharing Server. The user model assumes 80% of all ad hoc meetings use RDP-based application sharing and 20% PSOM. For scheduled meetings, the user model assumes that application sharing uses 50% PSOM and 50% RDP.
       
      Assumptions: Meetings with one participant use no RDP application sharing. For meetings with two participants: For scheduled meetings, the model assumes 20% RDP application sharing. For ad hoc meetings, the model assumes 10% RDP application sharing.
       
      25% remote access.
      15% anonymous.
      10% federated.
      50% internal.



    Duncan Blake, Enterprise Voice Architect, Unify2

      
    • Edited by Duncan Blake Tuesday, March 3, 2009 6:01 AM Adding signature
    Tuesday, March 3, 2009 5:58 AM
  • Duncan,

    I was simply stating that the guidelines doin't mean that 5000 users can all be having VOIP, Audio or Video conferencing calls all at the same time on the specified hardware shown.  The 5000 users could all be signed into OCS and working 'normally' at the same time: meaning some on IM conversations, some on Audio conferecing, some on Enterprise Voice calls, etc.  Not 5000 concurrent media streams.  I wasn't stating anything different than Byron's text (or Jens' from the Ignite materials).
    Jeff Schertz, PointBridge | MVP | MCITP: Enterprise Messaging | MCTS: OCS
    Monday, March 9, 2009 8:18 PM
    Moderator
  • Jeff, I'm pretty sure we both have a solid understanding of this, but I've fought for *years* to have even the concept of "maximum" users removed from all the documentation and replaced with clearer guidance about what the "5000 users" number (let alone 30K and 125K) actually means. It makes for an easy answer, but it's misleading.

    To those from outside a *Microsoft*
    UC background, especially in the broader PBX world, "maximum users" generally means exactly that. Unlike OCS, many products have very definite limits. An administrator can enable or have connected a maximum number of users/endpoints, and not one user more. This goes back directly to the physical hardware model of PBXs and conferencing bridges, and until quite recently was commonly carried through in the design and (especially) licensing models from most of the incumbent vendors in IP PBX and conferencing products.

    OCS is radically different in that way, even with the slow changes coming to the incumbents. For instance, Cisco recently changed their licensing model to allow an option for all in one licensing, enabling easy expansion of licenses to match your actual needs, but the underlying technology *still* cuts off your ability to enable ONE more user than your currently installed license authorizes. If you were to try to enable a user 5001, you CAN’T. The licensing model has started to catch up with (and is closely modeled on) Microsoft’s, but it doesn’t mean the technology has changed. It’s still based on emulating a legacy, TDM ,circuit switched world, and the old school PBX’s physical hardware limitations.

    The combination of software with open APIs and commercial, off-the-shelf hardware (and the scalability and flexibility that enables), is a key differentiator for OCS, one that usually gets lost when simple rules are presented like “SE supports a maximum of 5000 users”.



    Duncan Blake, Enterprise Voice Architect, Unify2

    • Edited by Duncan Blake Monday, March 9, 2009 10:07 PM And the fonts.
    Monday, March 9, 2009 10:04 PM