This article is now available on GamingLives because they’re nice like that.
You may have noticed the new link under My Sites over there on the right of the page ->
The Angry Admin is the new home of all my IT related postings, rantings, ravings and, on rare occasion, insights. I’ve backposted a bunch of stuff from this blog, but most of it is Brand New Material, so please enjoy.
He says: “We have got to continue to encourage the market to innovate and experiment with different business models and ways of providing consumers with what they want.
“This could include the evolution of a two-sided market where consumers and content providers could choose to pay for differing levels of quality of service.”
He also suggests that content makers could be charged for the first time for the use of the ISP’s networks – provided they too were clear about what they were getting.
How many times do we have to say this? Slashdot (for example) already pays their ISP for bandwidth to host their content. It is not, therefore, OK for my ISP to then charge Slashdot again for me to access that content. Just like it’s not OK for Slashdot’s ISP to charge me to access that content, because I already pay my ISP for that. This is what Peering agreements are there for and if ISPs don’t feel they’re getting a fair deal then they need to take that up with the other service providers, not the people at the end of the pipe.
This is on top of the fact that this “market” idea for QoS will inevitably end up with ISPs acting like TV companies. “Get our basic package to access the internet very slowly at low priority, only £9.99/month. Want to be able to use the iPlayer during waking hours? Get our BBC pack for only £4.99/month extra. Sorry, but due to a dispute with Google over pricing, we’re unable to offer our Search Engine pack this month, so you won’t be able to find anything on the internet”. And so on.
As someone in the middle of a transition between Exchange 2007 SP3 and Exchange 2010 SP1, I have to ask; MS Exchange Team, what were you smoking when you came up with the interoperability options here?
2003 to 2007 was pretty decent, you could deploy your 2007 CAS servers more-or-less directly in place of your 2003 OWA front-end servers and they would happily serve 2003 mailboxes up to people. Management tool interop was lacking a bit, but that was excusable as 2007 was, at least, a totally new set of tools based on .NET/Powershell and they generally wouldn’t let you do anything to a 2003 mailbox that would break it horribly.
With 2007 to 2010 though, you can’t do any of that. You have to keep your 2007 CAS and HT servers around because the 2010 ones won’t play nice with 2007 mailbox servers, but then the 2010 CAS servers can’t connect to 2007 mailboxes. Except they can, if you copy the 2007 binaries onto them. Except that only works if there isn’t a 2007 CAS server in the same AD site as the 2010 CAS server. So, short of creating new AD sites for all your 2010 mailbox servers you have to have at least one AD site with both 2010 & 2007 CAS servers, which works OK internally, but if you’re publishing to the internets (and who isn’t these days?) then you start to run into issues. There are various articles about this (like this one) but basically you have to create a new internet-facing DNS entry for the 2007 CAS, move the 2010 to the old internet-facing DNS name, change the ExternalURL value on the 2007 CAS to match the new DNS name, change the internal DNS so that there’s an entry for the new DNS name (because Exchange treats other AD sites as “External” as well), buy a new trusted SSL Certificate for the new DNS name (or wildcard it) and pray to God that you’re only publishing 2007 CAS servers from a single AD site; otherwise it gets so complicated that your brain will try and kill itself to escape.
If you think that sounds bad, then wait; it gets better! You can’t use the 2010 management tools (which are now 64-bit only – unless you enjoy Powershell Remoting) to manage 2007 mailboxes. Well that’s not entirely true, you can so some things, just not everything and it’s the same with using the 2007 tools on 2010 mailboxes. It’s all documented on The MSExchangeTeam Blog and it’s a huge mess – if your helpdesk staff (or whoever else manages your mailboxes day-to-day) aren’t really on the ball there’s a good chance you’ll run into problems while the 2007->2010 transition is in progress.
All this is in addition to all the subtle syntax changes they’ve made to a lot of the management Cmdlets so that things which were valid commands in 2007 don’t quite work properly in 2010; I’m looking at you, Import-ExchangeCertificate – let’s go from importing a CA-supplied .cer file to importing the binary contents of said file as a Byte Array supplied as a command line argument, because that’s much easier.
I really like Exchange – 2007 SP1 onwards was top-notch – and 2010 has some great new functionality, but they’ve really dropped the ball when it comes to installation, upgrading, migrating and transitioning.
I thought people only used “12345” on their luggage.
This is an old one, but I’ve only just managed to find a solution after searching on and off for several months; we’ve had a couple of machines that developed the problem but it was never really considered serious enough to put a lot of effort into solving.
Scenario: You have a machine with some element of SQL 2005 installed; be it simply the management tools or the full-on server with all the trimmings. This machine claims, via WSUS or Windows Update, that it needs Visual Studio 2005 SP1, but the install keeps failing. If you run the update manually, it keeps asking you for “Microsoft Visual Studio 2005 Premier Partner Edition ENU – Disk 1”. Browsing provides you with a filename “vs_setup.msi” but the only one you can find on your machine is part of the .NET Framework 3.5 and isn’t the one it’s looking for.
Solution: Point the installer to the “vs_setup.msi” file located in the “Tools” folder of your SQL 2005 install media.
If you install Exchange 2010 into a forest with multiple domains then you may come across this issue.
When you are trying to enumerate or move system mailboxes within your Exchange 2010 organisation, you will not typically get any results returned unless you use the -DomainController switch and specify a DC from the root domain as this is where Exchange creates most of the system mailboxes. Without the -DomainController switch, it will use a DC in your current domain, which won’t be able to see any accounts in its parent(s).
Get-MailboxDatabase | Get-Mailbox -DomainController <dcname.root.domain>
This will typically come up when trying to remove the first (i.e. default) mailbox database created when you installed your 2010 mailbox servers.
As per http://www.vmadmin.info/2010/07/error-upgrading-vmware-tools.html; if you’re getting an “Error Upgrading VMware Tools” when trying to do an automated upgrade of VMware Tools from vCenter, or by clicking the “Upgrade” button on the VMware Tools GUI, you need to either:
- Delete C:\WINDOWS\Temp\VMwareToolsUpgrader.exe for Windows guests, or
- mkdir /tmp/vmware-root for Linux guests
Seems like yet another case where a bit of installer detection/handling logic would avoid these problems every occurring.
Be warned; if you attempt to upgrade an Exchange 2010 RTM install to Exchange 2010 SP1 and you do not have the correct Powershell Execution Policy in place (and I’m not entirely sure what that is, it’s not documented anywhere obvious but it appears that Unrestricted works – although some have said that it doesn’t – and I can assure you that RemoteSigned doesn’t) it will not warn you, it will not avoid it, it will simply break halfway through the install and leave your server in a state whereby the Exchange binaries are all deleted, half your Windows services are disabled and all the Exchange cruft is still in the registry. The error is akin to the following:
The following error was generated when "$error.Clear();
& $RoleBinPath\ServiceControl.ps1 EnableServices Critical
" was run: "AuthorizationManager check failed.".
The only fix I’ve found for this, after sorting the Powershell Execution policy is to delete all the Exchange keys from HKLM\Software\Microsoft\Exchange and HKLM\Software\Microsoft\ExchangeServer, restart all the disabled services (IIS, WMI, Remote Registry, etc) then run the Exchange 2010 RTM “setup.com /M:RecoverServer”, wait for it to complete and then attempting the SP1 install again.
All I can say is thank god I didn’t test this on a server that happened to have the correct Execution Policy and then subsequently deploy it into production onto one that didn’t.
Update: Thanks to Martin for pointing me to http://support.microsoft.com/kb/981474 – it looks like it’s not so much what the Execution Policy is set to, but how it’s set. Seems like a really stupid oversight to me; surely Microsoft must have expected people to use GPOs to set Powershell Execution Policies – at the very least some detection logic in the installer to warn the user would be nice.
If, like me, you manage hundreds of Desktops and Servers, sooner or later you’re going to come across one with a completely broken .NET install that no amount of uninstalling, reinstalling, patching and fiddling will fix properly.
It will strip out any installable version of the .NET framework upto and including 4.x and, so far at least, it has always managed to fix my broken installs.
Usual caveats apply, see the original blog post for more details.