IT Blog – Jesper Ravn

Microsoft Windows Live Services er en kombination af Web Applications og programmer du kan downloade og installere.
Mange af disse services er stadigvæk i rivende udvikling.
http://livecom.spaces.live.com/
http://liveside.net/

Du kan downloade den samlede Windows Live pakke her:
http://www.windowslive.com/Home

Windows Live – Keeping your life in sync
http://windowslivewire.spaces.live.com/blog/cns!2F7EB29B42641D59!17757.entry

Dette er en kort blog-post omkring de “Windows Live Services” jeg benytter p.t:

Windows Live Hotmail (bliver bla opdateret med dynamisk data udvidelse over de 5 GB + Web Messenger + Contact Manager)
http://mailcall.spaces.live.com/

Windows Live Writer (bliver opdateret, så man direkte kan indsætte video sekvenser fra forskellige sources ex. MSN Soapbox + YouTube)
http://windowslivewriter.spaces.live.com/

Windows Live Messenger:
http://messengersays.spaces.live.com/

Microsoft Office Live Workspace:
http://workspace.officelive.com

Windows Live SkyDrive (bliver opdateret med 25 GB storage)
http://skydriveteam.spaces.live.com/Blog/cns!977F793E846B3C96!11672.entry?wa=wsignin1.0

Windows Live Mesh (Opdateret med Mac og Windows Mobile devices)
Du kan med den nuværende beta service af live mesh synkonisere filer mellem din live desktop og dine fysisk pc’ere/Windows Mobile, som du har tilføjet til Live Mesh.
Derudover kan du lave en remote desktop til dine fysiske pc’ere i Live Mesh.
Ovenstående kan på sigt give en lang række fordele i forhold til Projekt deling – Udvikling  – Support mfl.
https://www.mesh.com/Welcome/default.aspx
http://blogs.msdn.com/livemesh/
Live Mesh and Windows Mobile
http://blogs.msdn.com/livemesh/archive/2008/04/21/live-mesh-as-a-platform.aspx

Jeg blev kaldt ud til en XenApp installation (OS = Windows 2003), hvor der på alle XenApp serverne var kommet et udsædvanligt højt memory forbrug for processerne Outlook og IE.
Det medførte en ustabil drift i hele farmen.
 
I stedet for at bruge Process Explorer og kigge efter plugins og mulige memory leaks, valge jeg her at benytte Microsoft’s Debug Diagnostic Tool v1.1.
Jeg installerede den på en af XenApp serverne og lavede et fuldt userdump af en af de Outlook processer der havde et forhøjet memory forbrug.

Debug Diagnostic Tool generer herefter en dmp-fil, som default ligger i “C:\Program Files\DebugDiag\Logs\Misc”.

Næste step er at importere dump-filen (Add Data Files) og vælge “Start Analyses”.
 

Herefter bliver der udformet en rapport over allokeret memory, samt loadet moduler, for den specifikke outlook process.

Endvidere for man en top 10 liste over såkaldt heap memory.

Ved at klikke at klikke på det første link (0×028e0000), kan jeg nu se det loadet modul, som tager mest reserved memory.
 

Jeg kan herefter gå tilbage “Module Name” listen og konstantere at det er McAfee VirusScan scan engine der giver problemer.
 

Jeg udfører samme øvelse for en IE process og kan se at problemet er det samme her.

Løsningen blev at opdatere den nuværende VirusScan 8.0i til nyeste version 8.7i på alle XenApp serverne, som også har en nyere scan engine..case closed……
Relevant info/link til ovenstående:

For kenel dump til Vista og Windows 2008, kan man her benytte den nye Crash Analyzer, som kommer med “Microsoft Desktop Optimization Pack 2008 R2″.

For Vista og Windows 2008, har man nu ligeledes mulighed for at lave samme user-mode dump inde fra “Windows Task Manageren”.

 
 
The Official MDOP Blog:
http://blogs.technet.com/mdop/default.aspx

Giving the Microsoft Diagnostic and Recovery Toolset (DaRT) a Try:
http://windowsteamblog.com/blogs/windowsexperience/archive/2007/11/12/giving-the-microsoft-diagnostic-and-recovery-toolset-dart-a-try.aspx

Using the Microsoft Debug Diagnostics Tool to Create Dump Files:
http://support.citrix.com/article/CTX108889

Debugging Tools for Windows – Overview:
http://www.microsoft.com/whdc/devtools/debugging/default.mspx

NT Debugging Blog:
http://blogs.msdn.com/ntdebugging/default.aspx

The Hot Blog:
http://blogs.technet.com/hot/

The Change Analysis Diagnostic tool for Windows XP is available:
http://support.microsoft.com/kb/924732

Jeg er i mindre skala begyndt at implemetere server core med Hyper-V i diverse produktionsmiljøer.
Her har jeg oplevet et problem med NLB. Når man feks, vil installere sine Exchange CAS/HUB server i NLB unicast setup, får man efterfølgende nedenstående fejl.

Løsningen er her at indsætte den statiske MAC adresse fra NLB clusteret på begge CAS/HUB servernes NLB network adapter.
Det gøres som følger – Jeg har her 2 CAS/HUB servere (WIN-CASHUB-001 og 002)
Jeg starter “Network Load Balancing Manager” på WIN-CASHUB-001 og opretter NLB clusteret med WIN-CASHUB-001, som den første node.
Jeg lader den fejle og skriver herefter “nlb ip2mac clusterIP” og kopierer unicast MAC.


Herefter laver jeg en shutdown af WIN-CASHUB-001 og indsætter unicast MAC, som en statisk MAC adresse på NLB network adapteren.

Jeg starter WIN-CASHUB-001 og sikre mig at den nu har status som “Converged”
Samme øvelse fortager jeg for WIN-CASHUB-002. Jeg tilføjer den til NLB clusteret lader den fejle og indsætter herefter unicast MAC på dens NLB network adapter.
Man skulle nu have et funktionsdygtigt NLB cluster i unicast mode.
 
Hvis man ikke ønsker at kører med statiske mac adresser, kan man her benytte “legacy network adapter”, som dog er langsommere idet de er emuleret.

The Differences between a the “Network adapter “and the “Legacy Network adapter”
http://itbloggen.se/cs/blogs/micke/archive/2008/01/22/hyper-v-the-differences-between-a-the-network-adapter-and-the-legacy-network-adapter.aspx

Som udgangspunkt installere jeg også hver gang nedenstående hotfix, når jeg konfigurere et nyt hyper-V NLB cluster.
http://support.microsoft.com/kb/953828