oh, sorry. I would just go with the Spring 10 and then upgrade, that's what i've done, it works a treat. There's no real benefit to waiting as you'll just have a few less setup files in your setups folder.
Is it always Spring that they make installable, so you can have a Spring Clean :)
Will look at dns, it's just stupid and niggly. I've had it loads of times and it's a simple fix usually.
Yeah, I know going from the the 2010 Spring Clean CD (nice one!) will give me the same result, but with all the changes they've made recently (.NET 4, Windows 2K8 R2 / SQL 2K8 R2 support etc) I just like a clean slate.
Clean slate is sort of why i'm doing it, though i needed to get my testing in early. Wasn't the need for .Net removed again?
I've half solved my issue, it wasn't DNS, it was firewall. I don't know what i need to allow for it to work. I followed the M$ article on it, with usual sql ports and sqlsvr.exe but still no joy, the only way is if i turn it off, or enable an Allow All programs rule.
Anyone got any ideas for Windows 2008 R2, with SQL 2008 R2....?
Have you checked the errorlog for SQL to see exactly which port it's using?
Originally Posted by vikpaw
Yep, it doesn't work. I've seen that solution before and it didn't work then either. Finally got it sussed, and hope it's all ok, took the system off the domain as part of the troubleshooting but that shouldn't be a big issue.
Originally Posted by Janit
Ended up allowing sqlservr through and also sqlbrowser, it was that latter one i'd forgotten about, because it's not in Program Files it's in %ProgramFiles% (x86)\Microsoft SQL Server\90\Shared\sqlbrowser.exe and i forgot to look there.
Both those allowed through as Inbound and all seems okay at the moment apart from a domained client is struggling to see the DocServer but that's a DNS thing as a local virtual client is fine.
The browser service manages the fact that it may want connections on any port, so in that respect is easier to manage. There is a way to force client and server to use a fixed port, but i'm just glad it's working now as i need it to go live tomorrow.
Just turned off the sqlserv - rule and it still works! Not sure i'd trust it, and haven't got time to test, the M$ article didn't really make it clear.
Glad you got it working, Vik! I don't think I would have thought about looking at the firewall. Has it changed in R2?
Not really, it's just very secure. I knew to look there, it's even in the KB about reason 0 and says to go to M$, just not really knowing all the ins and outs, i didn't think about the (x86) folder. Why would SQL 2008 R2 need to put a core (my view) service there, backwards compatibility i guess. I dont know, but the M$ article was not clear.
Originally Posted by NorthernSands
I'm playing around abit at the mo' as the combo of rules affects speed at least that's what i think. I'm convinced there are multiple ways to access the server and if one fails it tries a different method, as having all rules disabled makes for quick access. At least it's something that can be tweaked later. Just need the accountant to go and test FMS for me. :)
Then go live bukra insha'allah ;)
Would you believe without the sqlservr.exe in the rules, and just browser, the login takes 32 secs, then down to 27 secs on a virtual XP box.
With the sqlserv.exe exception in the rules, it only takes 7 secs!
So far tested on a vm XP client and a Win7 physical client with similar results.
What i have found now is that the docstorage isn't visible to the win7 client. the only difference is that it's on a different vlan, but it never had a problem when it was connected to the live sims server. :(
:doh: DOH! stupid stupid.
So in the firewall rules that were created for the docserver by default, there is a little area called scope where the remote clients were set to local subnet only, so nothing outside my VLAN could connect. ARGH!
The installable 2011 is in KB 110102 I thought i had posted it elsewhere but couldn't find it, so just in case others come here looking...
and KB 111219 will upgrade that to Summer 11. :)