n case you aren’t familiar with Global Catalog Servers, they are simply domain controllers that have been designated to perform the Global Catalog server role. When you create an Active Directory forest, the first domain controller in the forest is automatically assigned the Global Catalog server roll, because every forest requires at least one Global Catalog server.

The Global Catalog server performs a variety of tasks, both for Windows and for Exchange. Since my primary focus in this article is Exchange Server, I don’t really want to get into the Global Catalog server’s Windows related function. I will tell you though, that if a Global Catalog server is not available, then nobody will be able to log into the domain except for the Administrator.

As you can see, the Global Catalog server performs some critical functions at the Active Directory level, but its role in relation to Exchange Server is just as critical. In order for clients to be able to send and receive mail, both the Outlook client and the Exchange Server must be able to query a global catalog server. Without access to a Global Catalog server, Outlook clients will not be able to open the Global Address List or resolve the e-mail addresses of message recipients within the forest.

Global Catalog Server Placement

Now that I have given you an idea of why Global Catalog servers are so important, let’s talk about placement. Given the fact that any domain controller that’s running Windows 2000 or Windows Server 2003 can be designated to act as a Global Catalog server, it might be tempting to just designate every domain controller to act as a Global Catalog server. In most cases this is a bad idea though. Global Catalog servers produce quite a bit of traffic related to the replication process.

Over the years, Microsoft has released several different guidelines for Global Catalog placement, many of which are contradictory. One set of guidelines states that you should place a Global Catalog Server into any site that contains a server that’s running an application that makes use of port 3268 (the Global Catalog lookup port). Exchange Server is such an application, so if you were to follow this rule, then you would want to place a Global Catalog server into any site that contains an Exchange Server.

Another Microsoft document that I read suggested placing a Global Catalog server into each site, regardless of what the site is used for. I tend to think that this is the best approach, given the critical nature of Global Catalog servers, and the fact that clients make use of the global catalog during the logon process. Microsoft does state however, that a site doesn’t need a Global Catalog server if the site does not contain any servers running Global Catalog dependant applications (such as Exchange), contains fewer than 100 users, and is directly connected to a site that does contain a Global Catalog Server.

Keep in mind that this is a generic guideline though. The recommendations change depending on the size and topology of your network. For example, in large organizations with lots of Exchange mailboxes, it is possible for a Global Catalog server to become overwhelmed. To keep that from happening, Microsoft recommends having one Global Catalog Server for every four mailbox servers. Therefore, if a site contained eight mailbox servers, then you would want to place at least two global catalog servers in that site.

Of course not every network is large enough to have multiple sites. If you have a single site, single domain network, then it is safe to go ahead and designate all of your domain controllers to act as Global Catalog servers. In this type of environment, all of the domain controllers contain full copies of the Active Directory anyway, so the additional resource consumption caused by having multiple Global Catalog servers will be minimal.

Summary

Being that Global Catalog servers are so critically important to the Active Directory and to Exchange, it is important to make sure that your network uses them in an optimal manner. In this article, I have provided some general guidelines to Global Catalog server placement.

Enterprise Project Management (EPM)

Enterprise Project Management (EPM), dalam hal luas, adalah bidang pengembangan organisasi yang mendukung organisasi dalam mengelola dan integrally beradaptasi sendiri untuk perubahan dari transformasi.

Dalam beberapa tahun terakhir, dengan adopsi umum (TI) praktek pemerintahan, Enterprise Manajemen Proyek telah menjadi lebih spesifik: sedangkan di tahun 1990-an secara umum telah fokus pada pengelolaan satu proyek, disusul di dekade meletakkan lebih fokus pada kenyataan bahwa proyek adalah kemungkinan untuk tidak hanya menjadi satu dalam perusahaan. Proyek bersama dengan banyak proyek-proyek lainnya di perusahaan, atau mungkin bagian dari satu atau lebih program. Hal itu dapat memanfaatkan (manusia) sumber daya yang digunakan bersama antara lain proyek.

Dalam rangka untuk memfasilitasi pemerintahan, telah menjadi penting untuk dapat mengelola, memantau, dan menilai status semua proyek (dan aset lainnya, tentu saja) di perusahaan, melalui satu set (diutamakan seragam) Enterprise Proyek Manajemen proses, metode dan paket aplikasi.

Biasanya, organisasi yang mengadopsi Enterprise Proyek Manajemen menjadikan cara kerja mungkin membuat sebuah Project Management Office (PMO), pilih dan mungkin mengadopsi Proyek Manajemen Metodologi seperti PRINCE2 atau PMBOK (atau membuat milik metode), dan mungkin memilih dan menerapkan perangkat lunak sistem untuk mendukung usaha Manajemen Proyek. Bahkan lebih baru evolusi Enterprise Manajemen Proyek adalah tidak hanya rencana untuk melacak dan mengatur proyek-proyek yang ada, namun untuk menciptakan sebuah portofolio (anggaran per ukuran, kalender per tahun, per tahun anggaran, bisnis per baris, dan lain-lain) yang ada dan yang akan datang (permintaan) proyek

Sama seperti dengan portofolio saham, Portofolio Manajemen Proyek adalah kegiatan proyek yang memilih untuk tetap dalam portfolio (karena nilai diantisipasi) dan yang untuk membuang (karena obsoleteness atau karena mereka tidak akan menghasilkan nilai yang pada awalnya dihitung).Portofolio Manajemen proyek meliputi pembuatan berbagai skenario untuk memutuskan adalah yang paling optimal portofolio (untuk tahun tertentu, bisnis, anggaran, dan lain-lain). Setelah isi portfolio yang telah disepakati, itu merupakan kunci untuk terus-amati bagaimana setiap proyek yang berkembang dari segi kualitas, biaya dan jadwal.

Dari TI perspektif manajemen, Enterprise Management dasarnya berarti perusahaan-luas jaringan administrasi, yang semakin kompleks. Jaringan perusahaan lingkungan tidak lagi terikat ke satu vendor, apalagi satu platform. Semakin banyak, perusahaan intranets adalah multidomain, multiprotocol, Multiplatform sistem. Mereka berisi hardware dan sistem operasi dari jumlah yang berbeda, persaingan vendor. Situasi ini membuat administrasi overhead yang dapat dengan mudah membuat biaya tersebut memiliki jaringan terlalu tinggi untuk semua tetapi terbesar dan paling menguntungkan organisasi.

Pelaksana Proyek Enterprise Management toolset perlu dipertimbangkan dalam cahaya dari organisasi Manajemen Proyek maturity dan metodologi, proses dan struktur yang sedang di tempat. Ada banyak organisasi yang dapat mendukung implementasi jenis ini terutama untuk. Peralatan yang mendukung usaha Manajemen Proyek termasuk kolaborasi Enterprise Project Management perangkat lunak seperti EPM Live dan Wrike.