Sorry, I meant primary site *server*. Availability should be defined in services, not applications. To the folks relaying the information to you and/or make the statements, they don't understand or know the difference but it is quite different and much more than semantics. When they say they want application X available, they really mean that they want the end-user/critical services provided by Application X to be available. Thus, you need to sit down and determine what those end-user/critical services are that application X provides and determine how to make those highly available.
J From: [email protected] [mailto:[email protected]] On Behalf Of Ryan Shugart Sent: Wednesday, July 17, 2013 12:12 PM To: [email protected] Subject: RE: [mssms] SCCM uptime Thanks Jason. So when you say if my primary site is unavailable what MPs would clients be talking to, especially those clients who mainly talk to the MPs at the primary? I didn't think they could fall to a secondary site for management points etc. A whole lot of descussions need to happen with us as to just what does "available" mean. If a client can't report its inventory I don't think that's the end of the world personally. Let's say the worst happens and enough of the site is down that, say, servers miss a patchin g window and that has to wait for amonth. Again in my mind, bad but not the end of the world, (it doesn't justify 99.999% uptime) but this is where I can see some disagreeing. If we ever run a software portal and users can't access that, that might be different and at that point that might need 99.999% planning. But again, this is just me rambling, and I'm still waiting for some clarification here. Ryan From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Jason Sandys Sent: Wednesday, July 17, 2013 10:56 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] SCCM uptime Remember though, that having an application "available" does not mean that all of it is running, just that's critical services are available. Thus, if the primary site is not available, it's not an availability issue as long as you've got MPs and DPs available and accessible by the clients. J From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ryan Shugart Sent: Wednesday, July 17, 2013 11:47 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] SCCM uptime Nick: You got it exactly. We got a request from management to supply what would be needed to make all of our applications resilient with a 99.999% uptime yearly. I personally think they aren't fully aware of the implications of what they're asking for but not going there. So as far as SCCM goes I'd imagine all MPs would need to be clustered, possibly behind a load balancer or something like that, fully clustered database etc. correct? I've never worked in that kind of environment so don't know really what they look like. As far as the rest, I assume patching such an environment means using maintenance windows very carefully to make sure you only bring down one node of a clustered application at a time? We already do this to a small extent, it doesn't always work but that's not SCCM's fault. I'm sorry if my questions seem kind of silly, but as I said I've never worked or known anyone who has worked in that kind of environment, so don't know what normal procedures etc. are for those situations. Thanks. Ryan From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Nick Moseley Sent: Wednesday, July 17, 2013 10:08 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] SCCM uptime Ryan, do you mean that the business is requiring all applications (where SCCM itself is an "application") to be up and operating full time? It is possible to design ConfigMgr for high availability and redundancy, but that has real costs (time, resources, additional infrastructure management etc.) associated with it when in most situations it is not necessary. So it can be accomplished, but the question is what is driving the business requirement? Nick | http://t3chn1ck.wordpress.com From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of [email protected]<mailto:[email protected]> Sent: Wednesday, July 17, 2013 10:00 AM To: [email protected]<mailto:[email protected]> Subject: RE: [mssms] SCCM uptime SCCM respects maintenance windows, so if you have defined windows for servers you are ahead of a lot of companies. As for uptime, if your looking for uptime on the OS you might be able to pull that through inventory, but that is more the realm of Operations Manager. Christopher Catlett Consultant | Detroit Office 248-876-9738 |Fax 877.406.9647 Sogeti USA 26957 Northwestern Highway, Suite 130, Southfield, MI 48033-8456 www.us.sogeti.com<http://www.us.sogeti.com/> From: [email protected]<mailto:[email protected]> [mailto:[email protected]] On Behalf Of Ryan Shugart Sent: Wednesday, July 17, 2013 11:54 AM To: [email protected]<mailto:[email protected]> Subject: [mssms] SCCM uptime Hi: Has anyone set up an SCCM environment with a 99.999 uptime requirement, including planned maintenance? We've been asked by management to submit what we're going to need to do to provide that level of uptime for all applications, and I'm not even sure if its possible with SCCM? On a similar note, how do you handle patching/reboots in that kind of environment? Right now, we have set windows each month when servers can be rebooted, but I don't think that's going to work anymore. Thanks. Ryan Ryan Shugart LAN Administrator MiTek USA, MiTek Denver 314-851-74 (c) COPYRIGHT, MITEK HOLDINGS, INC., 2011-2013, ALL RIGHTS RESERVED ________________________________ This communication (including any attachments) contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it is strictly prohibited. If you have received this communication in error, please notify the sender immediately and then destroy any copies of it. (c) COPYRIGHT, MITEK HOLDINGS, INC., 2011-2013, ALL RIGHTS RESERVED ________________________________ This communication (including any attachments) contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it is strictly prohibited. If you have received this communication in error, please notify the sender immediately and then destroy any copies of it. (c) COPYRIGHT, MITEK HOLDINGS, INC., 2011-2013, ALL RIGHTS RESERVED ________________________________ This communication (including any attachments) contains information which is confidential and may also be privileged. It is for the exclusive use of the intended recipient(s). If you are not the intended recipient(s), please note that any distribution, copying, or use of this communication or the information in it is strictly prohibited. If you have received this communication in error, please notify the sender immediately and then destroy any copies of it.
