I think they are definitely in a bad spot overall. In their search for stability they have found trouble dealing with the bloat of their code.
Products like Exchange are good examples of this. They have started releasing them every few years, but many companies rely on email so heavily, and Exchange patching being so finicky and break prone that many companies just got to 2010, skipping 2007 altogether (the last two I worked for included).
And these, even on their "new" email system are already outdated by almost two versiosn. and due to their inability to support the code and bloat that comes from version to version a 2003 ->2013 upgrade isn't possible. So how do they fix that? How do they instill confidence in companies that you don't need an Exchange Certified Master to help with an version upgrade?
The same can be said for server and workstation releases but on a issue of scale and version control. To this day we have 1 or 2 2012R2 servers but still rely on 2008R2 and 7 at our core. I still have some 2003 boxes im decomming and it has be a pretty big pain to get through some of these upgrades with vendors. I don't want the headache of support 7, 8, 8.1, 10, 2008, 2008 R2, 2012, 2012R2, and whatever 10's server version is.... That's like 8 different code bases and software compatibilities I have to support. So what do we do? We trim the fat, 7 and 2008R2 only. We have a few 8.1 (surface testing)/2012R2 (Few enhancements like DHCP replication) and may consider a move to 10 when the EOL 7/2008R2.
I think they are definitely in a bad spot overall. In their search for stability they have found trouble dealing with the bloat of their code.
Products like Exchange are good examples of this. They have started releasing them every few years, but many companies rely on email so heavily, and Exchange patching being so finicky and break prone that many companies just got to 2010, skipping 2007 altogether (the last two I worked for included).
And these, even on their "new" email system are already outdated by almost two versiosn. and due to their inability to support the code and bloat that comes from version to version a 2003 ->2013 upgrade isn't possible. So how do they fix that? How do they instill confidence in companies that you don't need an Exchange Certified Master to help with an version upgrade?
The same can be said for server and workstation releases but on a issue of scale and version control. To this day we have 1 or 2 2012R2 servers but still rely on 2008R2 and 7 at our core. I still have some 2003 boxes im decomming and it has be a pretty big pain to get through some of these upgrades with vendors. I don't want the headache of support 7, 8, 8.1, 10, 2008, 2008 R2, 2012, 2012R2, and whatever 10's server version is.... That's like 8 different code bases and software compatibilities I have to support. So what do we do? We trim the fat, 7 and 2008R2 only. We have a few 8.1 (surface testing)/2012R2 (Few enhancements like DHCP replication) and may consider a move to 10 when the EOL 7/2008R2.