Saker som bör tas i beaktande om man har Outlook 2003 och Exchange 2010.

Exchange Teamet på Microsoft fortsätter att skapa fantastiska blogg-inlägg.
Will Duff har samlat ihop ett helt drös länkar med information kring problem som kan (och i vissa fall i princip helt säkert kommer) att inträffa om man har Office 2003 på klienterna och Exchange 2010 på mailservrarna.

De ämnen som tas upp är:
- Encryption
- New Mail notifications and UPD
- Address Book Service (Directory Access)
- Public Folders, Offline Address Book and Free/busy
- Opening Additional Mailboxes
- RPC over HTTP Connectivity
- Unified Communications

Hela posten läser man här:
http://msexchangeteam.com/archive/2010/04/23/454711.aspx

Passa även på att läsa kommentarerna, de är bra!

Skapa och lägga till uppdateringar i WSUS med hjälp av PowerShell.

En evig sanning har länge varit att WSUS endast kan användas för patchning av Microsoft produkter. Denna "sanning" är inte riktigt sann... Det går faktiskt att lägga till egna uppdateringar i WSUS, men det har varit ganska struligt.

Jason Lewis har på sin blogg ett inlägg från Curtis Sawin som handlar om hur man kan använda powershell för att lägga till egna MSP-filer (Swengelska: "Windows Installer Patchar").

Det är kanske inte helt tokenkelt, men för en lite större IT-miljö kan det vara enormt trevligt att kunna skjuta ut patchar för egenutvecklade applikationer eller liknande.

I stora drag gör man så här:
1. Define the MSP file to be published

2. Connect to the WSUS namespace
3. Create the catalog xml file in memory
4. Add the appropriate metadata (title, description, etc)
5. Save the catalog file to the file system
6. Publish the catalog and MSP file to WSUS

Hela artikeln med script och allt finns att läsa här:
http://blogs.technet.com/jasonlewis/archive/2010/04/26/automation-creating-and-publishing-an-update-via-powershell.aspx

Virtualisering och lagring (specifikt när det gäller lagring över IP-nät)

En serie med tre stycken mycket intressanta blogg-artiklar tar upp ämnet vad som händer när man lägger virtuella maskiner på delad lagring som ansluts över IP (i detta fall genom NFS)..
Det intressanta att ta med från artiklarna är inte bara vad som var problemet och hur man kom fram till lösningen (vilket i och för sig är ett vackert exempel på felsökning), utan även att för att få en lyckad virtualiseringslösning är det enormt viktigt att förstå hur alla komponeneter hänger ihop.
 Just i detta exempel är det VMware och NetApp-lagring, men det kan lika gärna vara XenServer eller Hyper-V som använder en EMC Celera som lagring.
Alla delarna är viktiga i en virtualiseringslösning och orsaken att det slår så hårt är för att här är det inte en server som blir påverkad utan kanske 10, eller 20 eller kanske 30(!) om man missar nått i designen.
Att en server sitter med dålig nätverksanslutning gör kanske inget, men om den servern i sin tur har 30 virtuella maskiner på sig, då är det 30 maskiner som påverkas... Sånt märks... :)

så för att bli en bra virtualiseringsmänniska behöver man kunna hårdvara, nätverk, lagring, backup och operativsystem... Detta är en stor bit att ta för en enda person, och det är troligen därför som det blir problem ibland... Ta hjälp av olika experter och se till att alla i teamet är ödmjuka och kan se att man är en del i ett projekt.

Nåja artiklarna var det ja. De kommer här:
Del 1 - Ballooning memory, shared storage & file I/O performance
Del 2 - Ballooning results are in!
Del 3 - Conclusion, and possible vindication

tre bra artiklar om virtualisering.

Duncan Epping skriver en del bra artiklar om VMware. Här kommer tre exempel som rekommenderas:
Cool new HA feature coming up to prevent a split brain situation! Det är en disskussion kring att när man använder VMware HA så blir det ibland split brain. Artikeln tar upp vad detta innebär och hur det hanteras i ESX 4.0.

What’s the point of setting “–IOPS=1″ ? Här rekommenderas även kommentarerna till artikeln.

Aligning your VMs virtual hard disks. Alla som inte gör detta förtänar att få sina datorer hemsökta av myror. Detta är inget nytt ämne, men jag träffar fortfarande folk som jobbar med virtualisering som inte tycker att detta är ett problem. Den svagaste punkten i en virualiseringslösning är oftast disk I/O. Här har vi en sak som i bästa fall kan halvera disk I/O. Varför inte göra det då? Det är ju inte direkt svårt....

Injicera VMware drivrutiner i en dator innan P2V...

En bra artikel om detta finns här: http://technodrone.blogspot.com/2010/03/inject-vmware-drivers-into-source-os.html
Där finns även hänvisning till en KB-artikel på VMwares site som beskriver ungefär samma sak.. :)

Om den siten är nere så kommer här en kopia:

All Windows Versions (vmscsi only)

To copy the appropriate disk controller driver from a working virtual machine with a Windows guest operating system:
Download the VMware SCSI Disk Controller driver diskette here.
Copy the contents of the floppy either by mounting it or extracting the files
Right-click vmscsi.inf and click Install. The VMware SCSI drivers are installed.
Restart the source machine to complete installation.

Windows XP / 2000 / NT (buslogic and vmscsi)
Find a working VM installed with the same OS. Export these 3 registry keys.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\BusLogic
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_104b&dev_1040
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmscsi
(Note: The vmscsi service registry key may not exist if VMware Tools is not installed on the virtual machine.)
Import these 3 registry keys onto your source machine.
Perform your conversion

Windows 2003 (lsilogic and vmscsi)
Find a working VM installed with the same OS. Export these 3 registry keys.
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\symmpi
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\CriticalDeviceDatabase\pci#ven_1000&dev_0030
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\vmscsi
(Note: The vmscsi service registry key may not exist if VMware Tools is not installed on the virtual machine.)
Import the registry keys onto your source machine.
Restart the source to complete installation.


Perform another conversion with VMware Converter.

Now will this be needed every time? No! I have performed many a P2V on all of the above Operating Systems - without any problems at all and without injecting the registry keys beforehand. But for the case that the conversion will fail - this should help you out immensely.


Personally - I would make this best practice and inject the drivers in by default