More problems with Windows 2008-R2-Vista-7 security elevation

Last week I wrote a rant about the changes MS has made due to its security elevation model implemented in 2008/R2/Vista/7. The post covered what is effectively turning the domain administrators group into a lepers colony, by effectively implementing built in and irrevocable Deny permissions to the administrators group on a computer or server.
Today I’ve just discovered another problem – along with the explanation that it is “by design”. This is the issue that when you elevate a process to administrative rights, it loses access to mapped network drives that it would otherwise have access to on your computer. I already knew this happened at command prompt level, but wasn’t prepared for seeing it occur when I tried to elevate a setup process that also happened to be running on a mapped drive. Although the setup process was able to elevate, it couldn’t find the drives including the one it was being run from (LOL). There is a means of working around this problem as described here.
Whilst I don’t regard rants as an effective means of communication it has served to make the point that these changes which MS have implemented in Windows (along with many others in their service model) have, in my opinion, significantly diminished their credibility to be able to claim they have produced a credible, professional grade product suitable for use by large enterprises in all the situations that would reasonably be encountered in large sites, or multiple sites. MS’s response to the increasing competition they face in various levels has not been to produce a better product, but to slash their costs and service levels, and find new ways of stamping out the competition.