Upgrade Exchange 2007 ke SP2

Sebelumnya saya pernah menulis sedikit informasi tentang Exchange 2007 SP2 (Exchange 2007 Service Pack 2). Nah, sekarang saya akan post capture tentang proses upgrade ke Exchange 2007 SP2. Skenarionya yang di dukung dalam proses in place upgrade ini adalah:

– Fresh Install Exchange 2007 SP2

– Upgrade langsung dari Exchange 2007 (non SP1) ke Exchange 2007 SP2

– Upgrade langsung dari Exchange 2007 SP1 ke Exchange 2007 SP2

Kebetulan server yang saya pakai untuk eksperimen sudah ada Exchange 2007 SP1, namun kondisi lainnya saya tidak tahu. Dalam hal ini, kondisi lain itu adalah pra syarat supaya Exchange 2007 bisa diupgrade ke SP2 dengan lancar. Jadi, sebelum melakukan upgrade, saya harus cek terlebih dahulu pra syaratnya.

Seperti yang kita tahu, setiap upgrade Exchange, maka ada perubahan yang dilakukan terhadap schema dari Active Directory. Maka dari itu, pastikan bahwa kondisi Active Directory anda tidak sedang bermasalah karena Exchange akan melakukan extend schema ke Active Directory, apalagi di Exchange 2007 SP2 akan disertakan schema Exchange 2010 sebagai persiapan jika anda ingin melakukan migrasi ke Exchange 2010.

Hal berikut yang harus diperhatikan adalah, pastikan uninstall semua interim updates yang ada. Interim updates adalah update atau patch yang sifatnya khusus (tidak dirilis ke publik) dan dibuat hanya untuk beberapa case khusus. Nah, dari 2 pra syarat utama, ternyata server yang akan saya coba upgrade memenuhi 2 kondisi tersebut. Jadi, langkah berikutnya saya menjalankan proses upgrade ini (file Exchange 2007 SP2 telah saya unduh sebelumnya). Setelah dijalankan, kita akan dihadapkan pada wizard layaknya kita ingin menginstall Exchange 2007 ataupun ketika ingin melakukan in place upgrade dari Exchange 2007 ke Exchange 2007 SP1:

Setelah itu, Exchange setup wizard akan melakukan pre-requisites check. Sama seperti wizard sebelumnya, Exchange akan menghentikan proses jika ada syarat yang belum terpenuhi:

Dan kita baru bisa melanjutkan proses upgrade setelah semua syarat terpenuhi:

Setelah selesai, saya lakukan test terhadap operasional Exchange 2007 pada umumnya dan juga integrasi dengan beberapa aplikasi 3rd party yang digunakan. Semua berjalan lancar.

Salam,

Raymond Engelbert

OCS Front End Service Down [Error 0xC3E93C23]

Bagi anda para pengguna LCS maupun OCS (Office Communication Server), jika server anda melakukan update terhadap KB974571, maka bisa dipastikan anda akan mengalami problem ini.

Problem ini sendiri telah di publish oleh OCS Product Team di blog nya http://communicationsserverteam.com/archive/2009/10/14/632.aspx, namun pada blog saya ini, saya akan coba menjabarkan kronologisnya.

Seperti yang telah disebutkan pada link tersebut, sebuah security update yang mengacu ke KB974571 yang merupakan tambalan terhadap celah keamanan MS09-056: Vulnerabilities in CryptoAPI could allow spoofing. Namun pada implementasinya terdapat Known Issue yang penjabarannya bisa dilihat disini http://support.microsoft.com/kb/974571. Nah, sebelum masuk ke kesimpulan, berikut contoh kronologis yang saya lihat sendiri.

Gejala pertama yang dirasakan sudah pasti bahwa user akan bilang bahwa Communicator mereka tidak bisa login. Jika kita melakukan inspeksi ke server OCS tersebut, akan didapatkan bahwa OCS Front End Service berada dalam kondisi down, dan jika kita mencoba untuk menjalankan service tersebut, akan muncul error:

Jika kita mencurigai bahwa service admin yang digunakan yang bermasalah, maka salah besar karena service admin yang sama yang digunakan oleh service lainnya bisa berjalan sempurna. Sekali lagi, hanya OCS Front End service yang bermasalah.

Hal kedua, jika kita perhatikan di Event Viewer, akan terdapat suatu clue yaitu Error code 0xC3E93C23:

Nah, karena penyebabnya adalah patch KB974571 tersebut, maka pastikan bahwa memang benar di server OCS tersebut terinstall security update tersebut:

Jika benar, maka uninstall security update tersebut lalu server akan meminta restart. Setelah selesai restart, perhatikan bahwa OCS Front End Service bisa berjalan normal kembali dan anda bisa login ke OCS.

Beberapa hal penting yang perlu diketahui:

1. Solusi ini sifatnya sementara sampai ada pengumuman resmi dari Microsoft mengenai solusi permanen nya, karena kasus ini sedang ditangani oleh tim Microsoft.

2. Impact dari KB974571 hanya terbatas pada kondisi dimana server anda terinstall OCS dan juga pada client yang terinstall Communicator. Khusus untuk Communicator, yang terkena impact hanya communicator versi trial/evaluasi.

Salam,

Raymond Engelbert

Virtual Machine di Hyper-V Nyangkut?

Bagi anda yang pernah mengalami kondisi ini, kira-kira gambarannya adalah seperti di gambar berikut:

Nah, baik menggunakan Hyper-V pada Windows Server 2008 maupun Windows Server 2008 R2, tentunya kondisi menyebabkan anda bingung. Yeap, ada beberapa virtual machine yang kondisinya nyangkut alias sudah nyala, tapi tidak hidup-hidup.

Beberapa hal yang pertama sering dicoba untuk melakukan solve terhadap kasus ini adalah dengan melakukan restart, baik restart services maupun restart server secara keseluruhan. Namun, bagaimana jika hasilnya nihil? Dan di Event Viewer pun tidak nampak ada clue yang bisa membantu.

Trik sederhana. Coba cek Task Manager anda. Lihat pada Performance, ternyata aman-aman saja:

Harapan terakhir ada pada tab Process. Jika diperhatikan dengan seksama, setiap virtual machine yang berada dalam kondisi menyala (baik normal maupun tidak normal), akan mempunyai sebuah proses yang dinamakan vmwp.exe yaitu proses Virtual Machine Worker Process:

Kalau diperhatikan lebih jeli lagi, proses yang sama mempunyai konsumsi memori yang berbeda. Pada gambar terdapat dua kondisi berbeda yaitu sebuah proses yang memakan memori sebesar kira-kira 10000 K dan 4000 K. Nah, jika kita lakukan komparasi berapa banyak jumlah proses dengan konsumsi memori tertentu dengan jumlah virtual machine yang sudah running ataupun yang sedang stuck, maka didapatkan sesuatu, yaitu virtual machine yang sedang stuck mempunyai konsumsi memori yang lebih kecil daripada virtual machine yang sedang berjalan dalam kondisi normal.

Cara mengatasinya, cukup kill proses dari virtual machine yang nyangkut tersebut, lalu lihat pada Hyper-V manager anda, semua virtual machine akan berada dalam kondisi running:

 

Dan jika kita perhatikan kembali konsumsi memori pada setiap proses, ukurannya sama:

NB: Konsumsi memori tiap virtual machine tidak selalu 10000 K, tapi bisa berbeda tergantung kebutuhan dan konfigurasi virtual machine.

Salam,

Raymond Engelbert