Event 4005 from source Winlogon is logged in the System log every 30 seconds on the second:
Event details:
Other than this, no error is logged and no complaints from users, everything seems to be working as expected.
Continue reading “Event ID 4005 from Winlogon every 30 seconds on load balanced server”
After patching one of our SQL servers it was acting strange. Suddenly, the reporting services service refused to service https requests, and the SCOM monitoring agent refused to start. The error message from the reporting server website as reported by opera was “Secure connection: fatal error 552”. This could be translated to either “Requested file action aborted, storage allocation exceeded”, which is an FTP status code, or “552 – Unknown authentication service call-back”, which is a more likely explanation.
Continue reading “Local System Certificate store pooched after windows update”
This is an annoying message that shows up in the Event Log on Windows servers and computers and won’t go away. The error was initially caused by a certificate update published by Microsoft at the end of 2010 containing expired root certificates. The error has continued to surface on systems though, so I am starting to wonder if it has more than one cause. One theory is that this happens when an administrator is logged or has an active but disconnected session on the computer while another administrator or some form of automation tries to install updates from Windows Update.
The error is detected in the Application Event Log. On Windows server 2008 it looks like this:
Event 11 from Microsoft-Windows-CAPI2
Or like this:
Event 4017 from CAPI2
On Windows Server 2003:
Event 11 from crypt32
Microsoft has released a fixit that has solved this problem for me on most of the servers I have applied it to: Fix it 50531. See KB 2328240 for details and a manual method. This fixit only works on Windows 2008/7 though, but the manual method should work for older versions as well, provided you substitute “Documents and settings” were it says “Users” in the KB.
The solution is to delete the files in the folders referenced in the KB. You have to check all users and system accounts, unless you know which user ran windows update when the problem first appeared on your system.
Service account profile folder locations:
User account profile folder locations:
After deleting the files, check back a couple of hours and see if the error resurfaces. If you want to test it immediately, download the “authrootstl.cab” file from the link in the event and try to install it.
A colleague of mine has written a small powershell script that seems to do the trick on Win2008R2 servers:
get-childitem -path 'c:\users' | where-object { $_.psiscontainer -eq $true } | foreach-object {
$contentfolder = join-path -path $_.fullname -childpath 'appdata\locallow\microsoft\cryptneturlcache\content\'
$metadatafolder = join-path -path $_.fullname -childpath 'appdata\locallow\microsoft\cryptneturlcache\metadata'
if (test-path -path $contentfolder ) { remove-item -path "$contentfolder\*" -force -verbose }
if (test-path -path $metadatafolder) { remove-item -path "$metadatafolder\*" -force -verbose }
}
This is quicker to implement than the “Fix it” or manual approach, and all our attempts have been successful so far.
Ved feilsøking av noen rare clusterproblemer begynte jeg plutselig å lure på hvordan clusterdisker var representert på den passive noden i et Windows 2008 cluster. De var nemlig ikke å se i Disk Management, og forsøk på failover av diskressurser feilet spektakulert og fullstendig. Litt forskning viste kjapt at joda, de skulle vært listet omtrent som dette:
Dermed måtte feilen være et annet sted. Litt mer fundering avslørte at vi hadde oppdatert bios og managementprosessor på dette clusteret for kort tid siden, og vi begynte å ane hvor grevlingen var. Av en eller annen grunn hadde ikke serveren fått satt riktig WWN ved omstart. Dette er et IBM HS22 blade med Qlogic HBA som får sine WWN fra managementmodulen, og en rask sjekk i SanSurfer avslørte at WWN ikke stemte overens med det som var definert i SANet. Dermed trengs en kaldstart av managementmodueln i bladet, noe som betyr å slå av serveren, trekke ut bladet, vente et minutt og sette det inn igjen. Deretter må man vente en 5 minutters tid mens IMM booter. Man kan se at den er ferdig ved at powerlyset i front av bladet begynner å blinke med betydelig langsommere takt. Først da vil bladet la seg slå på.
Update: Det har også fungert i enkelte tilfeller å ta en full shutdown av bladet, vente to minutter og så starte det igjen. Det er verdt et forsøk, da man sparer en tur til serverrommet.
Samme situasjon har jeg tidligere opplevd på HP BL460 blade. Disse har vanligvis Emulex-kort som liker å komme opp med blank WWN (00-00-00-…), eller med en WWN som begynner på 1 istedenfor 5. Dette er noe som er litt lettere å oppdage enn et nummer som er tilsynelatende riktig. Løsningen er den samme, ut med bladet for å få kaldstartet managementmodulen.
Dersom feilen oppstår på en helt ny server/nytt HostBusAdapter er det vanligvis firmware på HBA som er utdatert eller på annen måte ikke samsvarer med firmware til bladets managementmodul. Emulex liker å splitte denne i flere deler, en HBA bios og en HBA firmware, pass på at du oppdaterer alle. Og oppdater firmware på bladet samtidig. Det anbefales å bruke firmware fra bladeprodusenten og ikke fra Qlogic/Emulex. Pass også på at du oppdaterer firmwaren til den sentrale managementmodulen på IBM Bladecenter samtidig. Denne kalles AMM. På HP C7000 har man ofte Virtual Connect fibermoduler istedenfor fiberswitcher fra feks Brocade. Rent teknisk er det store forskjeller på AMM og Virtual Connect, men i denne sammenhengen er det viktigste at versjonene stemmer overens.
Under gitte forutsetninger kan man få slått på hibernation/dvalemodus på en Windows 2008 server som standard ved installasjon. Dersom serveren ved installasjon har mindre enn 4GB minne vil det bli opprettet en hiberfil.sys og hibernation vil bli slått på. Dette fordi den da tror at du kjører demo på en bærbar og derfor trenger støtte for dvalemodus om batteriet går tomt. Siden denne filen vil være like stor som fysisk minne vil den ta opp en del plass som det vanligvis er bedre å bruke til andre ting. Det kan slåes av ved å kjøre følgende kommando:
powercfg.exe /h off
Kommandoen må som de fleste andre systemkommandoer kjøres i et elevated command prompt (Høyreklikk og velg “Run as administrator”).
Det hender at maskiner med UEFI istedenfor BIOS nekter plent å starte opp etter at man har oppdatert UEFI. Det er da viktig å passe på at du har oppdatert management-modulen samtidig (ILO, IMM, DRAC e.l.). Dersom disse ikke er kompatible blir det bare rot. Det samme gjelder forsåvidt de sentrale managementmodulene i chassiet, de må ofte oppdateres samtidig som UEFI for at bladene skal kunne snakke sammen med chassiet. Eksemplene som er nevnt her er stort sett hentet fra IBM Bladecenter H med HS22 blade, men det meste er også opplevd på HP BL460. Flere av løsningene vil med litt fantasi fungere også på HP, eller om ikke ihvertfall peke i retning av en løsning.
Forsøk disse i rekkefølge til du får respons.
Og så fremt du ikke bruker IPv6, slå dette av på alle nettverkskortene.
Under gitte forutsetninger kan man ende opp med et ustabilt system etter oppdatering, der maskinen går en stund for så å gå i blåskjerm. En analyse av minidump ga meg følgende:
BUGCHECK_STR: 0x124_GenuineIntel
CUSTOMER_CRASH_COUNT: 1
DEFAULT_BUCKET_ID: DRIVER_FAULT_SERVER_MINIDUMP
PROCESS_NAME: System
CURRENT_IRQL: f
STACK_TEXT:
fffffa60`01b91958 00000000`00000000 : 00000000`00000000 00000000`00000000 00000000`00000000 00000000`00000000 : nt!KeBugCheckEx
STACK_COMMAND: kb
FOLLOWUP_NAME: MachineOwner
MODULE_NAME: hardware
IMAGE_NAME: hardware
DEBUG_FLR_IMAGE_TIMESTAMP: 0
FAILURE_BUCKET_ID: X64_0x124_GenuineIntel__UNKNOWN
BUCKET_ID: X64_0x124_GenuineIntel__UNKNOWN
Followup: MachineOwner
Dette gjentok seg en par tre ganger i løpet av 12 timer, så jeg feilmeldte. De hyggelige folkene hos IBM kunne da fortelle meg at jo, dette var en kjent feil. Det har seg nemlig sånn at dersom man hadde rett type ekspansjonskort installert i serveren så må man endre en av standardinnstillingene i BIOS. Mer spesifikt må man endre System Settings –> Devices and I/O Ports –> PCIe Gen1/Gen2 Speed Selection fra Gen2 til Gen1.
Tilleggskort som fører til denne feilen per 2010.11.12:
Broadcom 10 Gb 2-port Ethernet Expansion Card (CFFh) for
IBM BladeCenter, Option 44W4466, FRU 44W4469
Broadcom 10 Gb 4-port Ethernet Expansion Card (CFFh) for
IBM BladeCenter, Option 44W4465, FRU 44W4472
Emulex 8 Gb Fibre Channel Expansion Card (CIOv) for IBM
BladeCenter, Option 46M6140, FRU 46M6138
NetXen 10 Gb Ethernet Expansion Card (CFFh), Option
39Y9271, FRU 39Y9269
QLogic 2-port 10 Gb Converged Network Adapter (CFFh) for
IBM BladeCenter, Option 42C1830, FRU 42C1832
QLogic 4 Gb Fibre Channel Expansion Card (CIOv) for IBM
BladeCenter, Option 46M6065, FRU 46M6068
QLogic 8 Gb Fibre Channel Expansion Card (CIOv) for IBM
BladeCenter, Option 44X1945, FRU 44X1948
QLogic Ethernet and 4 Gb Fibre Channel Expansion Card
(CFFh) for IBM BladeCenter, Option 39Y9306, FRU 39Y9304
QLogic Ethernet and 8 Gb Fibre Channel Expansion Card
(CFFh) for IBM BladeCenter, Option 44X1940, FRU 44X1943
SAS Connectivity Card (CIOv) for IBM BladeCenter, Option
43W4068, FRU 46C4069
ServeRAID-MR10ie (CIOv) Controller for IBM BladeCenter,
Option 46C7167, CRU 46C7171
Innimellom når man installerer en ny w2k8 server blir det en konflikt i Windows update etter at man har kjørt den første gang. Lignende feil kan også oppstå senere.
Feilen gjenkjennes ved å se etter følgende:
• Eventid 4385 fra Servicing i systemloggen:
• Ikke mulig å kjøre windows update, for eksempel alle updates feiler.
• maskinen kommer med en popup ved pålogging som sier ”Unable to download updates from windowsupdate” eller noe i den dur.
• Hver gang du logger på får du beskjed om at du må restarte for å aktivere oppdateringer, selv om du nettopp har restartet.
• Maskinen går i en boot loop, der den bare kommer til ”Applying updates, stage x av 3” (Se fix 2 for denne)
For å korrigere dette kjøres Microsoft Fixit nr 50202 (ligger på http://support.microsoft.com/kb/971058 ). Pass på å hake av aggressive options når den starter opp. Samme fix kan brukes på klienter om nødvendig, og den løser de fleste windows update relaterte problemer. Fixen krever omstart av maskinen.
Sjekk at ting virker ved å kjøre manuell windows update etterpå.
Dersom man ikke korrigerer problemet og fortsetter å installere programmer, kan man ende opp med en maskin som nekter å starte. Den booter til ”Windows is applying updates, stage x of 3”, står der en stund, og så restarter maskinen. Den går altså i en loop.
For å korrigere denne feilen må man boote fra installasjonsmedia, velge Repair my computer, åpne ett konsollvindu og endre navn på filen [Drive]:\windows\winsxs\pending.xml. (Drive varierer, men er ofte D)
Etter omstart får man boote igjen, men windows update er pooched. Utfør fix1 for å korrigere.
Last ned og kjør MS Fixit fra
http://support.microsoft.com/kb/971058Den har to modus. Kjør den aggressive.
Denne artikkelen har fått en utvidet versjon her
Anbefalinger, vanlige feil og løsninger
Her finner du en del teknisk info og anbefalinger basert på erfaring. Kapittelet om løsninger forutsetter at du har lest dette kapittelet først.
Operativsystemet bør alltid ha en egen disk, fortrinnsvis C:. Man bør unngå å installere programvare på denne som ikke er en del av operativsystemet, og brukerdata skal fortrinnsvis ikke ligge her.
Brukerdata, det være seg dokumenter, profiler eller annet bør plasseres på en egen disk, for eksempel D:. Dette gjør at logiske feil på operativsystemdisken ikke like lett påvirker brukerdata, og forenkler senere utvidelse av kapasitet. (strømbrudd etc).
Om man bare har en fysisk disk eller ett raid array så er dette tilstrekkelig. Videre inndeling gir ingen særlig ytelsesgevinst. Har man derimot flere fysiske disker/array bør man lese videre. I det følgende brukes fysisk disk som betegnelse, men de samme fordeler gjelder for raid array, dvs ett array kan likestilles med en disk.
En logisk disk gir derimot ikke samme ytelsesforbedring dersom det er mer enn en logisk disk per array. Det samme gjelder for partisjoner på fysiske disker, det å dele opp en disk i flere partisjoner har liten innvirkning på ytelsen.
Databaser bør lagres på egen fysisk disk. Dersom databaseserveren har høy belastning bør videre oppdeling vurderes slik at transaksjonslogger og databasefiler splittes på egne fysiske disker.
Profiler, fellesområder og hjemmekataloger kan og med fordel skilles ut. Dersom man har mange brukere bør man splitte opp videre.
Active Directory kan også få egne fysiske disker, men om man har så mange brukere at man vurderer det, bør man heller splitte det ut på en egen server
Operativsystemdisk bør aldri fylles mer enn 60%. Dersom dette skjer vil fragmentering av filer på disken akselerere drastisk, og det hjelper ikke å slette filer igjen. Det vil også medføre problemer med MFT, se eget kapittel. Operativsystemdisken bør for øvrig være på minst 75GB til W2k3.
Datadisker kan fylles til 80%, da fragmenteringsproblematikken vanligvis avgjøres av hvilken type data det er tale om. Ved 80% må man utvide kapasiteten. Datadisker med stor filtrafikk/mange endringer bør ha mer ledig plass.
(Master File Table) er NTFS filsystemets innholdsfortegnelse og metadatakatalog. Den holder styr på hvilke filer som er lagret hvor og data om filene som navn, tillatelser, endringsdato osv. Denne er delt i 2 logiske deler, selve MFT og MFT Zone. MFT Zone er plass på disken som er reservert for utvidelse av MFT. Dersom MFT blir full, utvides den inn i MFT zone, slik at MFT blir litt større og MFT Zone litt mindre. Størrelsen på MFT Zone varierer, tidligere var standardverdien 12,5% av diskstørrelsen, men store disker og større filer har gjort at dette kan bli vel voldsomt. Dersom disken blir full vil filer bli lagret også i MFT Zone som da blir mindre. Dersom MFT blir fragmentert vil det få store konsekvenser for ytelsen. Om MFT Zone blir for liten kan man også oppleve en situasjon der det ikke er mulig å legge til filer på disken selv om det er ledig plass, fordi det ikke er plass til flere MFT entries.
Navn: En absolutt sti (For eksempel C:\temp\test.txt) kan inneholde opptil 32767 tegn (UTF-16). En enkelt mappe eller fil kan ha et navn på opptil 255 tegn.
Filstørrelse: Teoretisk maksimum er 16EiB (Exabyte, 1024 basert)
Volumstørrelse: Teoretisk maksimum er 264 – 1 clustere, men i WinXP er den implementert med 232 – 1 clustere. Med en clusterstørrelse på 4KiB får man 16TiB.
Når Windows installeres vil det lage en fil kalt pagefile.sys på rot systemvolumet, vanligvis på C:. Denne har en størrelse som kalkuleres ut fra hvor mye fysisk minne som er installert. Dersom man installerer mer fysisk minne blir ikke denne justert automatisk. Det vil medføre lavere ytelse, i ekstreme tilfeller kan ytelsen faktisk gå ned når man installerer mer fysisk minne. Derfor må man korrigere dette manuelt.
Innstillingen ligger under Systemegenskaper, Avansert, Ytelse, Avansert, Virtuelt minne, Endre. Anbefalt størrelse vises da på skjermen, og man kan velge øvre og nedre grense. Anbefaler at nedre grense settes lik anbefalt verdi, og at øvre grense settes til nedre grense * 1,5 for å hindre at pagefile.sys blir fragmentert. Om man har plassproblemer kan man plassere pagefile.sys på en annen disk enn systemdisken, men dette anbefales ikke. Det er dog bedre med pagefile.sys på en egen disk enn med en pagefile.sys som er for liten.
Se http://tweakhound.com/xp/virtualmemory.htm for informasjon om hvorfor du trenger en pagefile.sys uansett hvor mye fysisk minne du har.
Dersom du har 64 bits Windows 2008 eller nyere kan du bruke en mindre pagefile. Du kan sjekke hvor stor den bør være ved å installere Process Explorer (www.sysinternals.com), la den gå et par dager når serveren er under last, og deretter sjekke Peak Commit Charge. Det angir den høyeste summen av fysisk og virtuelt minne som har vært i bruk. Legg på 8Gib og trekk fra størrelsen på fysisk minne så har du et fint utgangspunkt.
Verdiene det refereres til under har de offisielle navnene ”max server memory” og ”min server memory”.
MS SQL server skal egentlig være i stand til å håndtere minneallokering automatisk. Erfaring viser dog at dette er en sannhet med modifikasjoner. Standardinnstillingen for størrelsen på minnebufferen er fra 0 til størrelsen på fysisk minne, dvs om du har 4GiB RAM så settes den til 0-4GiB. Over tid vil derfor minnebruken på en slik server nærme seg fysisk RAM.
Dette er vanligvis ikke noe problem for operativsystemet, siden operativsystemet krever mer minne ved behov og får det rimelig kjapt, men ved høy belastning kan dette bli en flaskehals. Dersom det er andre programmer installert på maskinen som ikke ber om mer minne men bare tar det de får ved oppstart vil problemet bli desto større, siden disse programmene da kan få særs lite minne tildelt og muligens ikke vil fungere.
For å unngå slike problemer bør man alltid stille maksimalverdien slik at det er noen hundre MiB fysisk minne ledig ved normal belastning. Dette sikrer at man alltid har litt minne tilgjengelig for andre prosesser og for å ta unna topper. Dersom serveren har installert andre tjenester som kan kreve store ressurser bør man redusere maksverdien ytterligere. Samme problemet oppstår om man har mer enn en SQL server instans på samme maskin. For å finne de riktige verdiene må man overvåke minnebruken over tid.
Det er og viktig å være klar over at dette kun regulerer bufferstørrelsen, SQL tjenesten bruker også annet minne.
Minimumsverdien bør settes en del under maksverdien for å sikre at det alltid er minne som kan frigjøres om behovet skulle oppstå, samtidig som det ikke bør være 0 om man ønsker å prioritere SQL ytelse. 75% av maksverdien er et passelig tall.
Dersom serveren har en annen hovedoppgave og SQL tjenesten bare fyller en birolle stiller det seg annerledes. Man bør da sette maskverdien betydelig lavere. Skulle SQLserver tjenesten komme opp i en minnebruk som går over maksverdien samtidig som serveren har lite minne tilgjengelig generelt sett bør man sette inn mer minne og øve maksverdien. Om den derimot aldri når minimumsverdien kan man trygt redusere verdiene.
Dersom du ikke har fulgt anbefalingen over og lurer på om du har støtt på noen av de problemene som da kan oppstå finner du noen løsninger her.
Alle disker blir før eller siden rammet av filfragmentering, uavhengig av hvilket filsystem som benyttes. NTFS inneholder rutiner som forsøker å redusere dette bl.a. ved å reservere plass rundt ei fil slik at den kan vokse litt, men etter hvert som disken fylles eller endringene blir mange vil fragmentering oppstå. Windows 2K og nyere har innebygget et defragmenteringsprogram som også kan fortelle deg hvor ille ståa er.(Tilbehør, Systemverktøy, Diskdefragmentering) Bruk defragmenteringsfunksjonen for å forsøke å rydde opp, kjør den eventuelt flere ganger.
Om dette ikke hjelper, eller om det dreier seg om en server med stor belastning som fort blir fragmentert igjen, vurder å anskaffe et helautomatisk defragmenteringsverktøy som Execsoft Diskeeper.
Bruk NTFSInfo sammen med diskdefragmentering for å finne tilstanden på MFT og MFT Zone. NTFSInfo kan lastes ned her: http://technet.microsoft.com/en-us/sysinternals/bb897424.aspx .
Resultat av ntfsinfo c:
NTFS Information Dump V1.01 Copyright (C) 1997 Mark Russinovich http://www.sysinternals.com Volume Size ----------- Volume size : 152617 MB Total sectors : 312560576 Total clusters : 39070072 Free clusters : 26494752 Free space : 103495 MB (67% of drive) Allocation Size ---------------- Bytes per sector : 512 Bytes per cluster : 4096 Bytes per MFT record : 1024 Clusters per MFT record: 0 MFT Information --------------- MFT size : 110 MB (0% of drive) MFT start cluster : 786432 MFT zone clusters : 814624 - 5670208 MFT zone size : 18967 MB (12% of drive) MFT mirror start : 19535036 Meta-Data files ---------------
Det er MFT Zone size som er det interessante i dette tilfellet. I eksempelet er den på 12% av diskstørrelsen og enorme 18,9GB og alt er i orden.
En analyse fra diskdefragmentering vil fortelle deg hvor stor del av MFT som er i bruk og hvorvidt den er fragmentert. Du kan få dette kjapt ved å kjøre kommandoen defrag c: -a –v. Eksempel på MFT delen av rapporten:
Fragmentering av hovedfiltabell (MFT - Master File Table) Total MFT-størrelse = 110 MB Antall MFT-poster = 108 425 Prosent MFT i bruk = 96 MFT fragmenter totalt = 2
Dette er et rimelig normalt resultat. Vanligvis vil MFT ha være på rundt 90% såfremt disken har vært i bruk ei stund og inneholder litt data, og MFT ha 2 fragmenter. Dersom MFT har flere fragmenter vil du få en betydelig redusering av ytelsen. Og skulle MFT Zone ha en størrelse som er mindre enn halvparten av MFT er det også et tegn på at noe er galt.
For å korrigere dette har man to alternativer: Enten formatere og legge tilbake data fra backup eller anskaffe et kommersielt defragmenteringsprogram som kan defragmentere MFT.
Du kan gjøre MFT Zone større på følgende måte:
Dette løser dog ikke fragmenteringsproblemet du har, men vil gjøre sjansen mindre for at det skjer igjen, såfremt du ikke fyller opp disken igjen.
For å finne ut om pagefile.sys fila på en disk er fragmentert, kjør kommandoen defrag c: -a –v. Eksempel på Pagefile delen av rapporten:
Pagefile fragmentation Pagefile size = 9,00 GB Total fragments = 2
Her har man altså en pagefile.sys i 2 deler. Dette er ikke bra, den bør fortrinnsvis være i en del. Defragmentering krever at disken har et sammenhengende filområde stort nok til å holde pagefile.sys, så defragmenter vanlige filer først. For å defragmentere pagefile.sys må man ha spesielle verktøy, som Diskeeper eller Sysinternals PageDefrag (http://technet.microsoft.com/en-us/sysinternals/bb897426.aspx).
For å utnytte minne over 4GiB på 32Bits versjonen av w2k3 server må man slå på støtte for dette. Vær obs på at de forskjellige utgavene av w2k3 server har begrensinger for hvor mye minne de støtter. Man trenger også en cpu med støtte for PAE. For å slå det på utfør fålgende:
sp_configure 'show advanced options', 1
RECONFIGURE
GO
sp_configure 'awe enabled', 1
RECONFIGURE
GO
sp_configure 'max server memory', 7000 -–Verdien anbefales satt til Fysisk RAM – 1GiB på en dedikert sql server men dette må testes
RECONFIGURE
GO
USE master;
GO
EXEC sp_configure 'show advanced option', '1';
RECONFIGURE;
EXEC sp_configure;