August 2007 - Posts

MOSS 2007: How to delete default Shared Service?
26 August 07 12:10 AM | cakriwut | 1 comment(s)

English (versi bahasa Indonesia)

You might already know that one of essential component in MOSS 2007 is the Farm’s Shared Services. Farm’s Shared Services serves all server in the farm for profiles, bussiness data catalog and many more. Default Shared Services is the first farm’s shared services that we create in our MOSS 2007 servers. If we ever create farm shared services, then any web applications listed in SharePoints configuration databases will be associated with any of farm shared services. And so this is a not turning back operation; once you make an association then “forever” MOSS won’t let you disassociate with it.

Sharedsvcerr3
You can see the “Delete” action is disabled by default – so , how to delete this kind of default Shared Services?
Of course we will use the unprotected tools from MOSS.

Let’s understand what happened if we issue “Delete” shared service command?

MOSS will present you to */_admin/deletessp.aspx page with ssp GUID as sspId parameter. The page would be seen as  */_admin/deletessp.aspx?sspID={GUID}

Hence if we want to delete any of shared service, we only need to call that page with correct sspId – and if we put the GUID of default shared service then it will be deleted too.

Find out the GUID by clicking “Edit Properties” link for the Default Shared Service.

Ssp2

You’ll come to */_admin/sspdetails.aspx?task=Edit&sspId={GUID}. And intuitively you know the rest is to use that GUID. When you run deletion procedure for default shared service, there would be error like this,

Sharedsvcerr2

You can ignore it, because it will delete the ssp anyway.

-o0o-

Indonesia (see English version)

Anda mungkin sudah tahu salah satu komponen penting di MOSS 2007 adalah Farm Shared Services. Farm Shared Service merupakan layanan bersama yang digunakan oleh semua server yang ada didalam konfigurasi farm di MOSS 2007; misalnya untuk melakukan sinkronisasi profile dengan Active Directory, business data catalog, search dsb.
Default Shared Services adalah shared service yang dibuat pertama kali didalam farm. Jadi pada saat pertama kali kita membuat farm shared services di MOSS, semua aplikasi web yang ada didalam database konfigurasi akan diasosiasikan secara otomatis ke farm shared service tersebut. Proses assosiasi tersebut hanya berlangsung satu arah, artinya jika suatu saat kita ingin menghapus shared service maka secara desain hal tersebut tidak dimungkinkan oleh MOSS.

Sharedsvcerr3
Kita bisa melihat bahwa perintah “Delete” secara default tidak dapat diakses – jadi bagaimana cara kita menghapus default shared service? 
Anda mungkin berfikir untuk mengapus database shared service, tapi tidak, kita akan menggunakan tools yang sudah disediakan oleh MOSS.  

Apa yang sebenarnya dilakukan jika kita meng-klik perintah “Delete” ?

MOSS membawa kita ke halaman  */_admin/deletessp.aspx dengan GUID ssp sebagai parameter sspId. Jadi halaman tersebut akan terlihat sebagai   */_admin/deletessp.aspx?sspID={GUID}

Jadi singkat kata, jika kita ingin mengapus shared service apapun, maka yang kita lakukan adalah memanggil halaman tersebut dengan dilengkapi parameter sspId yang dikehendaki. Jika kita masukkan GUID yang dimiliki oleh default shared service, maka dapat dipastikan default shared service juga akan terhapus. 

GUID dari shared service dapat dicari dengan meng-klik perintah “Edit Properties” seperti gambar dibawah.

Ssp2

Kita akan dibawa ke halaman */_admin/sspdetails.aspx?task=Edit&sspId={GUID}. Dan secara intuitif yang dilakukan selanjutnya adalah menggunakan GUID tersebut untuk memanggil halaman deletessp.aspx. 

Jika Anda melakukan prosedur menghapus default shared service seperti diatas, Anda akan menemukan error seperti ini, 

Sharedsvcerr2

Abaikan pesan kesalahan tersebut, sebab MOSS akan tetap menghapus default shared service seperti yang kita inginkan.

Share this post: | | | |
WingsAir / LionAir Delay? Ah itu sudah biasa
25 August 07 05:05 PM | cakriwut | with no comments

Hari ini sepulang dari Surabaya, saya mencoba lagi terbang dengan menggunakan airlines group LionAir, yaitu WingsAir. Terakhir kali kira-kira 4 bulan yang lalu saya menggunakan LionAir dan terjadi delay. Dan kejadian ini berulang hari ini ketika saya memilih WingsAir. Jadi, begitu melihat pengumuman delay penerbangan WingsAir (WN8985 , no 2 dari atas) – komentar saya “Ah itu sudah biasa”.

DSC01210

Terus terang saya bete, tapi mudah-mudahanan delaynya bisa “cukup lama”. Kalau delaynya cukup lama, otomatis saya punya hak untuk melakukan claim asuransi keterlambatan penerbangan – soalnya tiketnya dibeli dengan kartu kredit hehehe. Yah, kita tunggu saja.

 

Share this post: | | | |
MOSS 2007: Fixing SSOSrv error 0x80040e14
20 August 07 12:22 AM | cakriwut | 1 comment(s)

English (versi Indonesia)

Yesterday I tried to enable single-sign-on (SSO) webpart on one of our client's server. It was very strange since the webpart was tested well few month ago on other client - but not at this time.
The "GetCredentials" of "ISsoProvider" always throws an error:

ssofailed4

I have double checked SSO configuration in the server farm, and looks everything has been setup correctly - so what was wrong?

KB932917 is not available!
Further investigation in the events viewer, I've found error number 0x80040e14. The error description is non-sense, credentials configuration has been double checked and this is not the first sso implementation.

ssofailed6

Searching the problem in Internet direct me to an explaination from Chris Calderon and he referred KB932917 which is private link from Microsoft. It will be included in roll-up SP package, but when? We need it right at the moment.

Do it your self!
From that article, Chris already mention that the problem is; MOSS always validate IX_SSO_Credentials index.
So, I open SSO database in SQL Management Studio, and found that there only IX_SSO_TempCredentials index in dbo.SSO_Credentials table.

ssoqry

Using the same index creation statement, I create second index called IX_SSO_Credentials. Then I left database with two index in that table - and starting to validate our sso webpart again.

ssofailed7

And, thanks God - although we expect for the upcoming update but now everything is running well again.

--o0o--

Indonesia (English version)

Kemarin, untuk kesekian kalinya saya mengimplementasikan webpart single-sign-on (SSO) di salah satu mesin di client kami. Tapi kali ini saya mendapatkan keanehan, webpart tersebut gagal berfungsi - padahal ini bukan implementasi pertama kali. Terpaksa, visual studio debuging dihidupkan dan error muncul pada saat pemanggilan method "GetCredentials" dari interface "ISsoProvider".

ssofailed4

Terpaksa, dilakukan check-list konfigurasi SSO di webfarm dan semua sudah dikonfigurasi dengan benar - jadi apa yang salah?

KB932917 tidak tersedia!
Saya coba melakukan investigasi lanjutan dengan membuka event viewer. Disana ada error yang disebabkan oleh SSO dengan nomor 0x80040e14. Penjelasan bahwa credentials tidak dapat diambil sangat tidak masuk akal, sebab konfigurasi SSO ini sudah bukan yang pertama kalinya, dan credentials yang digunakan juga memiliki otoritas yang sesuai.

ssofailed6

Saya coba membuka internet dan menemukan penjelasan dari Chris Calderon dan disebutkan *** bahwa kita harus menggunakan hotfix KB932917 dari Microsoft. Saya coba membuka link tersebut dan gagal. Menurut informasi yang ada, hotfix tersebut akan dimasukkan didalam service pack MOSS 2007, tapi kapan? Padahal kita butuh hotfix itu saat ini!

Patching Manual!
Dari blog yang ditulis Chris, kita bisa lihat bahwa masalah utamanya adalah MOSS selalu menggunakan index IX_SSO_Credentials yang ada di database SSO.
Hmm, saya buka database SSO dengan menggunakan SQL Management Studio. Ternyata disana hanya ada index dengan nama IX_SSO_TempCredentials.

ssoqry

Tanpa pikir panjang, saya gunakan perintah yang sama untuk membuat IX_SSO_TempCredentials - dan saya buat index kedua dengan nama IX_SSO_Credentials. Jadi sekarang dbo.SSO_Credentials memiliki dua index yang sama dengan nama berbeda.

ssofailed7

Tanpa menunggu terlalu lama, saya sekali lagi mencoba webpart sso dan syukurlah bahwa patching manual tersebut berhasil; dan webpart sso dapat bekerja dengan baik seperti sedia kala.

Share this post: | | | |