[SQL Server 2012] Fake it to be SQL Server 2000

[Mastakilla]

Hallo,

We hebben voor ons werk een sterk gecustomisede Unicenter NSM 3.1 voor monitoring van servers.
Dit programma draait momenteel op Win2k3 met SQL Server 2000.

We zijn nu aan het proberen het aan de praat te krijgen onder VMWare met Win2012 en SQL Server 2012, maar dat blijkt niet zo eenvoudig.

Unicenter NSM 3.1 is een oud product en al lang niet meer ondersteund. Het draaien onder Win2012 en SQL Server 2012 is dan ook zeker niet officieel ondersteund.
Maar dan nog zou het enorm veel tijd / geld uitsparen als we het daaronder aan de praat krijgen.

Het probleem is momenteel nog de installer van Unicenter NSM. Dit maakt nl een database aan in SQL en configureerd deze vervolgens.
Hiervoor hebben we bv al de DB-Library DLL van SQL Server 2000 moeten registreren onder win2012.

Maar nu doet de installatie software blijkbaar nog wat extra checks op de versie van SQL (hij denkt dat SQL Server ouder is dan versie 6.0 )

Met SQL Query Analyser zijn we te weten gekomen dat de installer het volgende commando geeft:
"master..xp_msver ProductVersion"
Dan krijgt oa dit terug:
"2 ProductVersion 720896 11.0.3000.0"

Is er een manier om (tijdelijk) te forceren dat SQL het volgende geeft?
"2 ProductVersion 524288 8.00.2055"

Ik weet dat dit eerder SQL Server hacken is en waarschijnlijk niet aangeraden wordt maar het is hoogstwaarschijnlijk enkel nodig tijdens de installatie en kan nadien terug ongedaan gemaakt worden.

Alvast bedankt!

[CMD-Snake]

Mastakilla schreef op dinsdag 19 februari 2013 @ 17:45:
We hebben voor ons werk een sterk gecustomisede Unicenter NSM 3.1 voor monitoring van servers.
Dit programma draait momenteel op Win2k3 met SQL Server 2000.

[...]

Is er een manier om (tijdelijk) te forceren dat SQL het volgende geeft?
"2 ProductVersion 524288 8.00.2055"

Ik weet dat dit eerder SQL Server hacken is en waarschijnlijk niet aangeraden wordt maar het is hoogstwaarschijnlijk enkel nodig tijdens de installatie en kan nadien terug ongedaan gemaakt worden.

Dit klinkt als een heel erg slecht idee. Geen idee waar dat zit, maar ik vermoed diep in de bestanden van SQL Server. Dit lijkt me geen wenselijke werkwijze zeker niet in een productie omgeving. Let wel dat als duidelijk is dat je hebt zitten rommelen elke vorm van ondersteuning weg is. Je kan zo ook een heel instabiele omgeving maken. Stel dat die check vaker voorkomt. Dan loop je kans dat je pakket er zo weer mee stopt.

Kan je niet beter je huidige pakket upgraden naar een recente versie of een ander pakket kopen? Geen idee wat je wilt monitoren, maar bijvoorbeeld iets als System Center Operation Manager 2012 is heel erg te customizen. Dan heb je een recent pakket wat recente versies van SQL Server aankan. Dat is beter dan zitten hacken om een oud pakket op te starten.

[Mastakilla]

Ondersteuning voor dit product hebben we sowieso al vele jaren niet meer.
Voorlopig zijn we echter gewoon wat aan het proberen op onze eigen laptop met vmware- (dus nog geen risico)

Dat de kans groot is dat het nog steeds niet lukt als we de installatie gedaan krijgen is idd zeer groot.

Het product upgraden naar een recente versie is enkele jaren geleden al voorgesteld, maar dat bleek te veel werk (lees: te duur)

[CMD-Snake]

Mastakilla schreef op dinsdag 19 februari 2013 @ 18:16:
Ondersteuning voor dit product hebben we sowieso al vele jaren niet meer.
Voorlopig zijn we echter gewoon wat aan het proberen op onze eigen laptop met vmware- (dus nog geen risico)

Je SQL Server heeft ook ondersteuning vanuit MS erop zitten. Gaan hacken in je SQL Server kan ervoor zorgen dat die ondersteuning vervalt. Daarnaast een hele goede kans dat het vanuit je EULA ook niet toegestaan is.

Bovendien is het de vraag of zoiets stabiel blijft draaien. Stel dat die check regelmatig terug komt? Of dat de applicatie iets aanroept in SQL Server dat niet meer aanwezig is. Er zit wel wat verschil tussen SQL Server 2000 en 2012.

Dat de kans groot is dat het nog steeds niet lukt als we de installatie gedaan krijgen is idd zeer groot.

Het product upgraden naar een recente versie is enkele jaren geleden al voorgesteld, maar dat bleek te veel werk (lees: te duur)

Dit soort dingen gebeuren. Je hebt heel wat jaren uit je product gekregen, maar misschien is het tijd voor een upgrade of een heel ander pakket. Wellicht is een ander pakket goedkoper en kan hetzelfde of meer doen. Dan hoef je niet te zitten hacken en kan je er zeker van zijn dat je monitoring pakket werkt zoals bedoeld.

[JeroenV_]

Kun je niet het pakket laten installeren naar een tijdelijke sql 2000, daarvan de database backuppen/restoren naar sql 2012 en dan de connectionstrings aanpassen?

Hoe je anders een oudere versie zou kunnen faken weet ik ook niet, en ik heb ook mijn twijfels of dat uberhaupt kan.

[Razwer]

simpelweg gewoon niet doen. Neem een gedegen product wat wel gewoon supported is. Goedkoop is duurkoop op de lange baan. Wring jezelf niet in bochten om een houtje touwtje oplossing te bieden in een bedrijfsomgeving.

[Mastakilla]

Ik ga volledig akkoord met jullie advies en bedenkingen bij deze werkwijze.

Ik werk echter in een grote multinational, waar gezond verstand en vooral lange termijn denken uit den boze is. (managers kijken enkel naar hun cijfertjes van dat kwartaal)

Als er maw een werkende oplossing (hoe crappy ook) in elkaar kan geknutseld worden, zonder dat hiervoor een groot langdurig project bij opgestart moet worden, dan heeft dit vrees ik de voorkeur.
Vandaar dat we momenteel op VMware dit aan het proberen zijn.

De suggestie van JeroenV_ is idd een goed idee, maar SQL Server 2000 kan niet geinstalleerd worden op Windows Server 2012.

We zijn momenteel aan het proberen te vinden waar dit versie nummer is opgeslagen. We hadden het bijna gevonden door xplog70.dll te editeren, maar de versie die in deze dll staat wordt echter niet gebruikt en is ook lichtjes anders (v11.2100 vs v11.3000).
Andere suggesties zijn nog steeds welkom...

[Razwer]

Mastakilla schreef op woensdag 20 februari 2013 @ 14:45:
Ik ga volledig akkoord met jullie advies en bedenkingen bij deze werkwijze.

Ik werk echter in een grote multinational, waar gezond verstand en vooral lange termijn denken uit den boze is. (managers kijken enkel naar hun cijfertjes van dat kwartaal)

dan juist poot stijf houden en zeggen dat het niet kan. je moet je niet laten intimideren door die pennenlikkers en de cijfertjes. je krijgt waar je voor betaald.

[muppet99]

http://stackoverflow.com/...-version-using-powershell

Misschien is de software dusdanig ingesteld dat hij de registry uitleest. Let wel draai eerst een backup van de keys voordat je gaat frutten. Kan je het altijd nog terugzetten het artikel gaat dan wel over powershell, maar de post met de registrykeys kan eventueel de oplossing bieden. kan het zelf nu niet checken, zit namelijk niet achter een pc met SQL geinstalleerd

[ Voor 25% gewijzigd door muppet99 op 20-02-2013 15:43 ]

[Question Mark]

Mastakilla schreef op woensdag 20 februari 2013 @ 14:45:
Als er maw een werkende oplossing (hoe crappy ook) in elkaar kan geknutseld worden, zonder dat hiervoor een groot langdurig project bij opgestart moet worden, dan heeft dit vrees ik de voorkeur.

En als je gewoon eens kenbaar maakt dat een paar weken knutselen ook tijd en dus geld kost? Het break/even point is wel te bepalen lijkt me, dan weet je hoelang je er aan kunt knutselen..

Knutselen lijkt mooi, maar het is zo zonde als na een maand knutselen blijkt dat het niet werkend te krijgen is. Da's gewoon 176 uur weggegooid...

[CMD-Snake]

Mastakilla schreef op woensdag 20 februari 2013 @ 14:45:
Ik werk echter in een grote multinational, waar gezond verstand en vooral lange termijn denken uit den boze is. (managers kijken enkel naar hun cijfertjes van dat kwartaal)

Ik heb vaak genoeg (helaas) met dit soort managers te doen gehad. Maar je kan iets ook gewoon weigeren, zeker als je dit soort praktijken moet uithalen om iets nog gewerkend te krijgen. Bovendien kost dit hobbyen in de software ook tijd en geld.

Ik zou inzetten op een ander pakket en de kosten hoeven niet eens zo hoog te zijn. Stel je hebt al een van de System Center producten van MS. Als je een ander erbij wilt is dat vaak niet eens zo duur. En soms heb je ze al maar gebruik je ze niet. In dat geval is het dus "gratis" als je die licentie in gebruik neemt.

Als ik jou was zou ik gewoon eens de markt voor monitoringspakketen verkennen, zien hoe je huidige software contracten zijn en dan gaan rekenen. Als jij een goed verhaal op kan hangen is het zeer lastig voor managers om er onderuit te komen.

[BarthezZ]

CMD-Snake schreef op woensdag 20 februari 2013 @ 17:21:
[...]

Als ik jou was zou ik gewoon eens de markt voor monitoringspakketen verkennen, zien hoe je huidige software contracten zijn en dan gaan rekenen. Als jij een goed verhaal op kan hangen is het zeer lastig voor managers om er onderuit te komen.

Het werkt toch en kost nu niks? [/manager] Succes met daar tegenin gaan

[CMD-Snake]

BarthezZ schreef op woensdag 20 februari 2013 @ 19:05:
[...]


Het werkt toch en kost nu niks? [/manager] Succes met daar tegenin gaan

Maar het pakket werkt nu niet en zal ook niet gaan werken. (Even simpel gezegd.)

[Mastakilla]

Het pakket werkt momenteel wel, maar zal binnen enkele maanden gemigreerd moeten worden naar een andere locatie.
Op die andere locatie zullen ze waarschijnlijk zicht krijgen op het hopeloos verouderde OS / software dat niet meer aan de "standaarden" voldoet.

Er is uiteraard binnen ons bedrijf wel een standaard / modern monitoring pakket aanwezig (ben ff kwijt wat het is). Onze monitoring doet echter bepaalde zaken die blijkbaar niet gecoverd werden door dit pakket.

Dit is trouwens monitoring van Windows, Linux, SunOS, HP-UX en nog enkele custom OS (op Linux gebaseerd) waar geen enkele extra software op geinstalleerd mag worden (de meeste monitoring software heeft een agent nodig op de te monitoren machine)

Dit soort customization opnieuw ontwikkelen op een ander product, zou waarschijnlijk veel meer tijd kosten dan het tussen de uren door knutselen waar we momenteel mee bezig zijn.

Daarnaast is een beetje prutsen ook leuk en leerzaam om wat dingen bij te leren (dus geen verloren tijd). Zo hebben we nu ervaring op gedaan met VMware, Win2012, SQL2012, Process Explorer, Process Monitor, WinHEX, etc

[Razwer]

Leren is altijd goed, sterker nog, een must in dit vak. Vernieuwing is ook een must. Stilstand is achteruitgang.
Behalve een technische rol binnen een bedrijf hebben beheerders ook een adviserende rol, of dit nou officieel is toebedeeld of niet, het is naar mijn mening zelfs een verplichting die je hebt. Ik heb in mijn 13 jarige carriere (en redelijk wat banen en nog meer managers) weinig echt goede (IT) managers meegemaakt. Of ze waren technisch slecht (waarbij ze dus zwaar leunden op advies van de werknemers) of ze waren technisch goed maar simpelweg zwakke managers. In alle gevallen heb je iig de verantwoordelijkheid om het standpunt te nemen wat (op de lange baan) het beste is voor de organisatie qua techniek.
De algehele filosofie op IT gebied (ook wel automatisering genoemd) is automatiseren. Dat wordt vergemakkelijkt door standaardisering. Oud (legacy) maatwerk valt daar niet onder. Als het goed is zijn er bij alle beheerders die naar school zijn gegaan enkele basis principes bijgebracht, waaronder (maar niet gelimiteerd tot):
- Altijd voorbereiden op groei
- Altijd voorbereiden op de toekomst (upgrades/migraties)
- Security
- Documentatie/kennis overdracht

Met deze principes in gedachten, is een legacy product niet de juiste keuze. Kennis van onbekende en/of legacy producten is vaak lastig, security is outdated en/of niet aanwezig. Groeien kan vaak ook niet, en uprades en/of migraties worden bemoeilijkt.

Op de lange termijn en met deze aspecten in gedachten zijn de TCO veel hoger voor je legacy product dan voor een gedegen oplossing.

Als alternatief word SCOM genoemd, maar er zijn ook alternatieven voor SCOM.

Linux/Unix bakken waar niets op geinstalleerd MAG worden is een politiek besluit. Daar zal iets aan gedaan moeten worden. Als niemand dat taboe probeert te breken, zal er ook idd niets gebeuren en zal de organisatie verloederen wat uiteindelijk impact heeft op de algehele performance van het bedrijf. De CEO/board of directors gaat het dan opvallen en dan is jouw afdeling de gebeten hond.

Mijn sterke advies is, neem je verantwoordelijkheden en gooi dit legacy/maatwerk product overboord.

[demokert]

De Productversie moet je gewoon niet aanpassen, waarom zou je dat uberhaupt willen doen?
Sowieso een beetje rare constructie/check dattie de versioninfo gaat uitlezen.. als hij dit uitleest gaat hij dit gebruiken als een variable...wat als je die variable gewoon gaat zetten in je stored procedure.

Sinds SQL2012 is het ook niet meer mogelijk om de database in een compatibiliteit mode te laten draaien.. SQL 2008 is de laatste versie dit dit ondersteund voor SQL2000 databases.

Ik begrijp dat een bestaand systeem niet simpel over boord te gooien is zoals mijn voorganger hierboven al roept, maar dit is wel noodzakelijk, tot dan blijf je met deze oude software zitten en moet je de consequenties dragen bij het out of support zijn op 9 april van dit jaar.

conclusie: probeer die check voor de gek te houden.. door een harde variable in te zetten.. of het laatste...