Mendengar istilah virtual machine saya yakin sudah tidak asing lagi di telinga kita, namun bagaimana penerapannya virtual machine

Di lingkup pengembangan Active Directory secara virtual ?

Banyak dari teman-teman di komunitas menanyakan, apakah jika sudah ada teknologi virtualisasi maka active directory server bisa di buat virtual ?

Jawaban saya simple saja : bisa dan boleh.

Bisa artinya memang bisa kita banguan active directory server under virtual.

Boleh artinya memang boleh-boleh saja, tidak ada larangan untuk melakukan itu, hanya saja kita harus memastikan bahwa active directory server virtual ini

Selalu dalam kondisi up terlebih dahulu sebelum semua server yang ada di jaringan juga up, kenapa demikian, karena active directory server merupakan

Pusat dari authentikasi user name dan password yang di atur di jaringan windows.

Ada satu hal yang menarik di saat kita memiliki banyak sites cabang, dan di masing-masing sites tersebut ingin kita deploy active directory server,

Jaman Physical dulu, biasanya kita deploy active directory di suatu sites dengan cara deploy OS dari CD atau DVD, kemudian melakukan promote dan replikasi,

Replikasi ini yang cukup memakan waktu karena biasanya bandwidth antara sites cabang dengan kantor pusat sangat kecil untu melalakukan full replikasi.

Dengan adanya teknologi virtualisasi, maka cara di atas bisa kita abaikan dan siasati, cara barunya sbb :

1. Di kantor pusat -- deploy beberapa active directory server yang baru, misal dengan konsep single domain, kita bisa bikin langsung beberapa virtual machine

                                 active directory server sebagai ADC (Additional Domain Controller) dari DC (Domain Controller) yang utama, lakukan replikasi secara LAN.

2. Di kantor pusat -- semua ADC yang sudah di deploy tersebut (dalam hal ini misalnya di bangun under Microsoft Hyper-V), maka kita shutdown

                                 dan semunya kita export (cara lain dari backup dan clone).

3. Di kantor cabang -- ADC hasil export, kita hanya perlu menyiapkan hypervisor di physical server cabang yang ada (Hyper-V), kemudian kita lakukan import

                                   virtual machine.

4. Di kantor cabang -- pada saat ADC di Power up, sudah pasti pada saat OS (Operating System) naik, maka IP masih merupakan IP yang merupakan subnet

                                    kantor pusat, maka IP ini dapat langsung kita ubah sesuai dengan subnet IP kantor cabang.

5. Di Kantor cabang -- langkah terakhir adalah pastikan bahwa ADC yang sudah up di kantor cabang bisa saling contact dengan DC di kantor pusat,

                                     ini merupakan cara yang simple, kita cukup sedikit jeli di perubahan ip (A record) di DNS Server yang ada di tiap active directori

                                     baik itu DNS ADC di kantor cabang dan DNS DC di kantor pusat, force replication -- done.

Demikian, semoga bermanfaat untuk teman-teman sekalian.

Slamet Raharjo

MVP - Directory Service

 

 

 

Share this post: | | | |
Posted by sraharjo | with no comments

 Apakah teman-teman di sini yang menjadi Administrator Active Directory Server atau Domain Controller sudah cukup bisa tidur dengan tenang ?

Jika ya, ada beberapa hal yang ingin saya tanyakan sbb :

1. Apakah segala sesuatu tentang Active Directory yang sudah teman-teman bangun sudah di dokumentasikan semuanya sampai yang paling detail ?

2. Jika teman-teman memiliki beberapa staff yang di beri hak administrasi, apakah sering teman-teman control apa saja yang pernah staff kita lakukan ?

3. Apakah teman-teman ingat jumlah administrator yang memilki power terhadap semua active directory server yang ada, namanya siapa saja, powernya apa saja ?

4. Apakah teman-teman sering melakukan pengecekan maupun test terhadap GPO yang pernah di buat ?

5. Apakah user Guest sudah di disable dan user Administrator sudah di rename ataukah di biarkan apa adanya ?

6. Apakah DSRM Password sering di ganti oleh teman-teman semua untuk melindungi offline copy NTDS.DIT yaitu jantung databasenya Active Directory ?

Hal-hal yang saya sampaikan di atas baru sebagain kecil dari beberapa hal yang harus teman-teman perhatikan supaya tidur lebih nyenyak.

Selangkapnya teman-teman dapat pelajari link ini : http://technet.microsoft.com/en-us/magazine/2006.05.smarttips.aspx 

Demikian, semoga bermanfaat untuk teman-teman sekalian.

Slamet Raharjo

MVP - Directory Service

Share this post: | | | |
Posted by sraharjo | with no comments

Bagi teman-teman yang sudah terbiasa menjadi administrator Active Directory Server atau Domain Controller,

Sering kali ada permintaan dari user sebagai berikut :

Latar Belakang : Saya memiliki komputer dengan nama PC A dan login selama ini sebagai user A

Issue : Saya ingin agar user saya yaitu user A dapat login di semua komputer ( di semua PC), tetap khusus PC saya yaitu PC A hanya saya yang bisa login, bagaimana caranya ?

Solusi : Selama ini kita bisa dengan mudah setup di ADUC (Active Directory Users and Computers) yaitu masuk ke username user A tersebut,

            Klik Kanan -- Properties -- Log On to -- kemudian kita pilih All Computers, maka user A sudah bisa log on di semua PC.

            Tapi bagaimana perlakuan dengan user-user lain, misal user B, user C dan lainnya, apakah kita harus masuk satu per satu ke properties setiap username tersebut

            dan bagaimana mengatur supaya user B, user C dan lainnya tersebut tidak boleh login ke PC A ?

            Ada cara yang lebih efektif untuk pengaturan ini, yaitu kita cukup memanfaatkan fitur :

           1. Local Computer Policy - Computer Configuration - Windows Settings - Security Settings - Local Policies - User Right Assignment - Allow log on locally

           2. Local Computer Policy - Computer Configuration - Windows Settings - Security Settings - Local Policies - User Right Assignment - Deny log on locally

Fitur 1 dan 2 ini dapat kita gunakan sebagai solusi yang saling melengkapi, yaitu sbb :

           Jika kita memanfaatkan Fitur 1, artinya kita cukup memasukkan user A yang di allow untuk log on secara local ke PC A tersebut, yang tidak terdaftar artinya 

           Tidak dapat log on ke PC A -- artinya masalah selesai.

           Jika kita memanfaatkan fitur 1 dan 2, artinya kita bisa dengan mudah mengatur bahwa Deny policy lebih di utamakan di bandingkan dengan Allow Policy,

           Jadi misalnya di Allow Policy memperbolehkan domain users login ke PC A, maka jika kita inginkan bahwa user B tidak boleh login ke PC A maka cukup

           di bagian Deny Policy didaftarkan user B, artinya karena Deny lebih utama dari Allow, maka user B akan di Deny log on ke PC A.

 Demikian, semoga bermanfaat untuk teman-teman sekalian.

Slamet Raharjo

MVP - Directory Service 

 

Share this post: | | | |
Posted by sraharjo | with no comments

Apakah ada di antara rekan-rekan yang sudah mengalamai hal ini :

Suatu pagi, masuk kantor, ada beberapa user teriak, pak, komputer saya tidak bisa logi ke domain,

Errornya apa mas ?

Errornya ini pak : Trust Relationship Between This Computer and Domain is Broken, please contact your system administrator.

Walah, lah saya sebagai system administrator gak ngapa-ngapain, kok bisa muncul seperti ini.

Ada beberapa hal yang dapat mengakibatkan hal ini, sbb :

1. Komputer client tersebut pernah di system restore, dan kebetulan kembali ke suatu waktu yang ada "sesuatu banget" yang di tolak mentah-mentah oleh Domain Controller

2. Komputer tersebut kena virus, sehingga "sesuatu banget" tersebut rusak

3. Komputer tersebut ada issue dengan windows firewallnya, sehingga perubahan "sesuatu banget" tersebut tidak di kenal oleh Domain Controller sehingga di tolak.

Nah, apa sich "sesuatu banget" tersebut ?

Jawabnya : SC (Secure Channel).

Jadi, ternyata pada saat suatu komputer di jointkan ke domain, ada yang di sebut Secure Channel untuk jalan komunikasi antara komputer client dengan Domain Controller.

Lalu buatnya pake apa secure channel tersebut ???

Jika kita selama ini sudah mengetahui ada yang di sebut user name dan password yang biasa kita pakai untuk login komputer,

Nah, ada yang di sebut juga sebagai "Computer Password".

Wah, apalagi ya ini ?, Computer Password adalah password yang di generate otomatis pada saat komputer client di jointkan ke Domain Controller.

Computer Password dicatat di dua tempat, yang pertama di komputer client tersebut, kemudian yang satunya lagi di Domain Controller.

Jika ada issue yang menjadikan Computer Password yang ada di client komputer tersebut tidak sama lagi dengan Computer Password yang ada di Domain Controller,

Maka efeknya adalah error Trust Relationship di atas.

Lalu solusinya bagaimana ?, ada 2 cara sbb :

1. Disjoint komputer tersebut, kemudian jointkan kembali ke Domain

2. Menggunakan konsep Network ID

Kedua cara ini bisa di gunakan sebagai solusi masalah tersebut.

 Semoga Bermanfaat.

==Slamet Raharjo==

 

 

 

 

Share this post: | | | |
Posted by sraharjo | 1 comment(s)

Banyak di antara teman-teman di WSS-ID yang japri, dan masih bingung cara kerja waktu (Time Sevice) di suatu infrastructure yang sudah memiliki pondasi

Active Directory (Domain Controller) di company masing-masing.

Dalam kesempatan ini saya akan sedikit sharing, bagaimana Time Service ini bekerja.

Seperti kita ketahui bahwa, jika kita promote sebuah Windows Server menjadi Domain Controller, maka sudah dapat di katakan bahwa di suatu infrastructure tersebut

telah hidup sebuah server yang memiliki kemampuan luar biasa, yang mana kemampuan ini akan semakin kita rasakan jika benar-benar kita memahami

konsep dan cara kerjanya.

Hasil dari promote Windows Server menjadi Domain Controller yaitu adanya 5 Roles Super yang sudah siap di berikan perintah oleh kita untuk controll infrastructure, sbb :

1. Schema Master

2. Domain Master

3. RID Master

4. PDC Emulator

5. Infrastructure Master

Nah, yang kita sorot di sini adalah point yang ke-4 yaitu PDC Emulator, sebetulnya roles ini untuk apa fungsinya.

PDC Emulator ini ternyata berfungsi untuk mengatur konsistensi waktu yang ada di suatu infrastructure yang menjadikan Domain Controller sebagai pondasinya.

Artinya, semua resource komputer yang ada di jaringan, harus menginduk waktu (menit, jam, hari, tanggal, tahun) ke server ini.

Jika waktu sudah konsisten, sudah tentu semua IT Compliance juga bisa di pertanggung jawabkan.

Misalnya saja, sempat ada hacking ke suatu server, maka logs yang ada di server tersebut jika di bandingkan dengan logs di semua server yang di curigai

ada keterkaitan, maka secara waktu dapat di pertangungjawabkan, karena waktunya konsisten anatar waktu server yang satu ke server yang lain.

Berikut gambaran hierarki waktu tersebut, sbb :

1. Semua komputer client yang sudah di jointkan domain, akan menginduk waktunya ke Domain Controller terdekat secara logon server.

2. Semua Domain Controller yang ada di infrastructure, akan menginduk waktunya ke Domain Controller yang memegang roles PDC Emulator

3. PDC Emulator, ada 2 cara menginduk waktunya :

   a. Menginduk ke waktu yang ada di BIOS (CMOS) di sebut sebagai Hardware Clock, atau

   b. Menginduk ke waktu yang ada di external time source (Internet Time Server)

4. Kedua cara menginduk waktu tersebut sah-sah saja di lakukan, yang harus di pastikan adalah harus selalu di cek mengenai baterai CMOS-nya tidak ada masalah,

    Untuk Internet Tiem Server, harus di pastikan securitynya (Authenticate Credential) dan juga harus di jamin reachablenya (koneksi internet).

Semoga Bermanfaat.

==Slamet Raharjo==

 

 

Share this post: | | | |
Posted by sraharjo | with no comments

Jika kita berbicara tentang Data Korporasi, maka yang ada di benak kita adalah segudang data yang sangat sulit di maintain dan bagaimana data tersebut

bisa di akses oleh multiple user dengan security yang di set berbeda-beda untuk masing-masing user.

 Di samping data yang besar, yang paling mendasar adalah, bagaimana data tersebut dapat di jamin keberadaannya (HA- High Availabilitynya).

 Dalam kesempatan ini saya ingin sharing sedikit  mengenai FS (File Server) Teknologi yang di miliki oleh Windows Server.

Gambar di atas menunjukan, bagaimana suatu infrastructure FS di bangun dengan Teknologi DFS (Distributed File System) yang ada di Windows Server 2008 R2,

Teknologi ini harus memiliki pondasi Active Directory Environtment.

Tahapan-tahapan untuk mereplikasikan data antara data di FS yang satu dengan FS yang lain, saya tautkan sebagai berikut :

 

 

Semoga Bermanfaat.

== Slamet Raharjo, MVP ==

 

 

 

Share this post: | | | |
Posted by sraharjo | with no comments

Rekan, berikut satu lagi alur restoration AD, alur ini lebih di tekankan terhadap kerusakan AD (misal kerusakan salah satu DC) yang ringan

yang tidak terlalu berimbas secara global (forest wide accident), sbb :

Good Luck.

Share this post: | | | |
Posted by sraharjo | 1 comment(s)

Rekan, berikut sedikit saya sharing Alur Active Directory Database Restoration Procedures,

Prosedur ini dapat di manfaatkan in cases Active Directory (Domain Controller) yang kita miliki sedang sakit

dan sudah tidak bisa di sembuhkan dengan obat biasa, yang mau tidak mau harus dengan restoration proccess.

Good Luck.

 

Share this post: | | | |
Posted by sraharjo | with no comments

Berikut list port yang di gunakan untuk komunikasi dengan ataupun antar Active Directory.

Port tersebut harus di pastikan sudah di buka di firewall (windows firewall and another firewall).

 

  TCP UDP ICMP
RDP Remote Desktop 3389    
DNS DNS Download 53    
DNS Queries   53  
WINS Replication WINS 42    
WINS   42  
ICMP echo-request     8
info-request     15
mast request     17
timestamp     13
NetBIOS Services Name Resolution Service 137 137  
Datagram  Services (Browsing)   138  
Session Service (net use) 139    
SMB Input 445    
Output   445  
Remote Storm   1025    
NTP NTP 123    
NTP   123  
Content Replication Content_Repl 507    
Kerberos Kerberos-Secure   750  
Kerberos_v5 88 + 464    
Kerberos_v5   88 + 464  
LDAP LDAP 389    
LDAP   389  
LDAP over SSL/TLS 636 636  
Global Catalog 3268    
Global Catalog over SSL/TSL 3269    
Replication Active Directory RPCSS Dynamic    

Untuk Penambahan Port Tertentu yang ingin di lakukan melalui command prompt, dapat di lakukan

dengan mengetikan syntax netsh firewall, contohnya dengan command sebagai berikut :

netsh firewall add portopening tcp 3389 139_tcp_AD_PORTS enable
netsh firewall add portopening tcp 139 139_tcp_AD_PORTS enable subnet
netsh firewall add portopening tcp 445 445_tcp_AD_PORTS enable subnet
netsh firewall add portopening udp 137 137_udp_AD_PORTS enable subnet
netsh firewall add portopening udp 138 138_udp_AD_PORTS enable subnet
netsh firewall add portopening tcp 53 53_tcp_AD_PORTS enable subnet
netsh firewall add portopening udp 53 53_udp_AD_PORTS enable subnet
netsh firewall add portopening tcp 42 42_tcp_AD_PORTS enable subnet
netsh firewall add portopening udp 42 42_udp_AD_PORTS enable subnet
netsh firewall add portopening tcp 137 137_tcp_AD_PORTS enable subnet
netsh firewall add portopening tcp 1025 1025_tcp_AD_PORTS enable subnet
netsh firewall add portopening tcp 123 123_tcp_AD_PORTS enable subnet
netsh firewall add portopening udp 123 123_udp_AD_PORTS enable subnet
netsh firewall add portopening tcp 507 507_tcp_AD_PORTS enable subnet
netsh firewall add portopening udp 750 750_udp_AD_PORTS enable subnet
netsh firewall add portopening tcp 88 88_tcp_AD_PORTS enable subnet
netsh firewall add portopening udp 88 88_udp_AD_PORTS enable subnet
netsh firewall add portopening tcp 464 464_tcp_AD_PORTS enable subnet
netsh firewall add portopening udp 464 464_udp_AD_PORTS enable subnet
netsh firewall add portopening udp 389 389_udp_AD_PORTS enable subnet
netsh firewall add portopening udp 636 636_udp_AD_PORTS enable subnet
netsh firewall add portopening udp 445 445_udp_AD_PORTS enable subnet
netsh firewall add portopening udp 161 161_udp_AD_PORTS enable subnet
netsh firewall add portopening tcp 162 162_tcp_AD_PORTS enable subnet
netsh firewall add portopening tcp 42424 42424_tcp_AD_PORTS enable subnet
netsh firewall add portopening tcp 5000 5000_tcp_AD_PORTS enable subnet
netsh firewall add portopening tcp 5001 5001_tcp_AD_PORTS enable subnet

Good luck. 

 

Share this post: | | | |
Posted by sraharjo | with no comments

In any case, since domain controllers are the most important machines in a Microsoft-based environment, and having failed DCs hanging out there can have adverse effects on many network services, devices and applications, you should really consider carefully planning your setup, just like you would for physical servers. For example, here are some important considerations:

  1. If you virtualize your DCs, you should configure the VMs running the domain controllers to always start when the parent starts, no matter what their running state was (this is configurable in the virtual machine settings).
  2. If you virtualize your DCs, configure any other virtual machines to start automatically but with a delayed start time to allow the domain controllers to start up prior to the other virtual machines.
  3. If you virtualize your DCs, you should configure the domain controller virtual machines to shutdown (and not save state) if the physical computer is shutdown.
  4. Plan and test managing of the Hyper-V environment in case all the virtual domain controllers fails to start.
  5. You should NEVER use saved state/snapshots with domain controllers, unless there's only one DC.
  6. Just like in physical servers, ALWAYS have more than one domain controller.
  7. Spread the domain controllers across separate physical machines. There's no point running all DCs on the same Hyper-V host server if it fails for some reason.
  8. Disable time synchronization for the domain controllers.  They are supposed to be the source of time in the domain, and you don't want them to take the time from their host, which then takes the time from the domain controller.
  9. Make sure you plan, text and implement a good and working System State backup for at least some of your DCs. This is mostly true for Global Catalogs and FSMO Role holders.
  10. If you have more than one Hyper-V server hosting virtual machines running domain controller roles, you might want to plan a method of quickly transferring these VMs between the physical Hyper-V hosts. This can be accomplished by using Power Shell scripts or VM management tools such as SCVMM 2008.
Good luck, Happy VM Deployment.  //'); //]]> //'); //]]> //'); //]]> //'); //]]> //'); //]]> //'); //]]> //'); //]]> //'); //]]>
Share this post: | | | |
Posted by sraharjo | with no comments

DC DIAGNOSTIC COMMAND:

********* DCDIAG /S:DC1 >C:\DIAG.TXT (>c:\diag.txt = printing dcdiag info into c:\diag.txt file)

COMPAR- TWO DC's DIFF..

********* DSASTAT /S:DC1,DC2 /b:"CN=DOMAIN CONTROLLER,DC=domainname,DC=COM"

To verify communication with other domain controllers

********* netdiag /test:dsge

To ensure that the operations masters are functioning properly

********* dcdiag /s:servername /test:fsmocheck

To determine whether a site has at least one global catalog server

********* nltest /dsgetdc:domainmae /gc /site:sitename

To Verify Status of Global Catalog Server

******* dcdiag /v /s:servername | find "%"

To Verify whather a site has Bridgeheads Server

***** Repadmin /Bridgeheads /Verbose

To monitor the replication progress on a new global catalog server

********* dcdiag /v /s:servername

To Detecting Null Server-Reference Attributes

********* ntfrsutl ds > c:\ntfrsutl.txt

To Rollback Defualt Security temple before appling new Security template

*********

secedit /generaterollback /cfg c:windows\security\templates\securedc.inf /rbk ooops.inf /log ooops.log

*****To Redirect Computer folder to new Organization Unit****

rediremp ou=lockdown,dc=domainname,dc=com ****

****Replication DC to DC****

Repadmin /Syncall

Repadmin /Syncall /A /e /P

*****GPO Troubleshooting*****

dcgpofix /target:domain

dcgpofix /target:DC

dcgpofix /target:Both

*****Apply Security template on local PC or Server

Secedit /Configure /db c:\dc3.sdb /cfg c:windows\security\Template\secureserver.inf /log sercureserver.log

****To Creat Application partition on DNS Server by using DNSCMD****

dnscmd Server1 /createdirectorypartition app1.companyname.com

dnscmd Server1 /enlistdirectorypartition app1.companyname.com

dnscmd Server1 /unenlistdirectorypartition app1.companyname.com

dnscmd server1 /deletedirectorypartition app1.companyname.com

*****Troubleshooting Replication ******

repadmin /kcc

repadmin /showreps

repadmin /bridgeheads

DSASTAT /S:DC1,DC2 /b:"CN=DOMAIN CONTROLLER,DC=domainname,DC=COM"

DSASTAT -S:domaincontroller1;domaincontroller2

dsastat -s:rosebud;milquestoast

dcdiag /test:topology

dcdiag /test:replication

********* Time Services Managements ****

w32tm /config /manualpeerlist:"ntp.colby.edu, tick.gatech.edu" /update (US-EST Time)

net time /querysntp

w32tm /monitor

*****FSMO******

----Find which server holding what roles---

Netdom Query FSMO

dsquery server -hasfsmo rid

dsquery server -hasfsmo pdc

dsquery server -hasfsmo infr

dsquery server -hasfsmo name

dsquery server -hasfsmo schema

****To FSMO Details****

Dcdiag /test:knowsofroleholders /v

****To Transfer FSMO Roles from one DC to another DC*****

Ntdsutil:

Ntdsutil:roles

fsmo Maintenance: Connections

Server Connections: Connect to Domain_Controller

Server Connections:Quit

-> fsmo Maintenance:Transfer PDC or RID OR Domain naming master or Schema master

**To Seize Roles**

-> fsmo Maintenance:Seize Schema master or Rid master or PDC master or Domain naming master

***Cleaning Metadata***

ntdsutil:

ntdsutil:metadata Cleanup

Metadata Cleanup:Connection

Connection:Connect to Server Servername (Domain Naming Master)

Quit

Select Operation Target

List Domain

Locate the domain you want to remove the metadata (Pick Number)

select domain number (Number= 0 or 1)

List Sites

Select Site Number (Number= 0 or 1)

List Servers in Site

Select Server number (Number = 0 or 1)

Quit

remove Selected Server

Quit

Quit

******How to change DSRM Password********

ntdsutil:set DSRM password

Reset DSRM Administrator Password:reset password on server servername

Reset DSRM Administrator Password:reset password on serve null (Local)

quit

****How to Restore AD Databse****

ntdsutil:auth-restore

authoritative restore:Restore subtree ou=sales,dc=temple,dc=com (i.e Subtree Restore)

authoritative restore:Restore Databse (Entire AD Database from last backup)

authoritative restore:Restore Object (Object Only)

Repadmin /option <Servername> +disable_inboubd_rep (Disable replication)

Repadmin /Syncall /A /e /P (BIG GUN)

Repadmin /option <servername> -disable_inbound_rep (Enable replication)

Share this post: | | | |
Posted by sraharjo | with no comments

            Certain domain and enterprise-wide operations not well suited to multi-master placement reside on a single domain controller in the domain or forest. The advantage of single-master operation is to prevent the introduction of conflicts while an operation master is offline, rather than introducing potential conflicts and having to resolve them later. Having a single-operation mastermeans, however, that the FSMO role owner must be available when dependent activities in the domain or enterprise take place, or to make directory changes associated with that role.

The Active Directory Installation Wizard (Dcpromo.exe) defines five FSMO roles: schema master, domain master, RID master, PDC emulator, and infrastructure. The schema master and domain naming master are per-forest roles.

 The remaining three, RID master, PDC emulator, and infrastructure master, are per-domain roles. A forest with one domain has five roles. Every additional domain in the forest adds three domain-wide roles. The number of FSMO roles in a forest and potential FSMO role owners can be determined using the formula ((Number of domains * 3)+2).

A forest with three domains (A.com, with child and grandchild domains of B.A.com and C.B.A.com) has eleven FSMO roles:

1 Schema master - forest-wide A.COM

1 Domain naming master - forest-wide A.COM

3 PDC emulators (A.com, B.A.com, and C.B.A.com)

3 RID masters (A.com, B.A.com, and C.B.A.com)

3 Infrastructure masters for each respective domain. (A.com, B.A.com, and C.B.A.com)

When you create the first Active Directory domain controller of a forest, Dcpromo.exe assigns all five roles to it. When you create the first Active Directory domain controller of a new domain in an existing forest, the system assigns all three domain

roles to it. In a mixed mode domain containing Microsoft Windows NT 4.0 domain controllers, only the domain controllers that are running Microsoft Windows Server 2003 or Microsoft Windows 2000 Server can hold any of the domain or forest wide

FSMO roles.

 

FSMO availability and placement

Dcpromo.exe performs the initial placement of roles on domain controllers. This placement is often correct for directories with few domain controllers. In a directory with many domain controllers the default placement is unlikely to be the best match to your network.

On a per-domain basis, select local primary and standby FSMO domain controllers in case a failure occurs on the primary FSMO owner. Additionally, you may want to select off-site standby owners in the event of a site-specific disaster scenario.

Consider the following in your selection criteria:

  • Ø If a domain has only one domain controller, that domain controller holds all the per-domain roles.
  • Ø If a domain has more than one domain controller, use Active Directory Sites and Services Manager to select direct replication partners with persistent, "well-connected" links.
  • Ø The standby server may be in the same site as the primary FSMO server for faster replication convergence consistency over a large group of computers, or in a remote site in the event of a site-specific disaster at the primary location.
  • Ø Where the standby domain controller is in a remote site, ensure that the connection is configured for continuous replication over a persistent link.

General recommendations for FSMO placement

Place the RID and PDC emulator roles on the same domain controller. It is also easier to keep track of FSMO roles if you host them on fewer machines.

If the load on the primary FSMO load justifies a move, place the RID and primary domain controller emulator roles on separate domain controllers in the same domain and active directory site that are direct replication partners of each other.

As a general rule, the infrastructure master should be located on a nonglobal catalog server that has a direct connection object to some global catalog in the forest, preferably in the same Active Directory site. Because the global catalog server holds a partial replica of every object in the forest, the infrastructure master, if placed on a global catalog server, will never update anything, because it does not contain any references to objects that it does not hold.

Two exceptions to the "do not place the infrastructure master on a global catalog server" rule are:

Single domain forest:

In a forest that contains a single Active Directory domain, there are no phantoms, and so the infrastructure master has no work to do. The infrastructure master may be placed on any domain controller in the domain, regardless of whether that domain controller hosts the global catalog or not.

Multidomain forest where every domain controller in a domain holds the global catalog:

If every domain controller in a domain that is part of a multidomain forest also hosts the global catalog, there are no phantoms or work for the infrastructure master to do. The infrastructure master may be put on any domain controller in that domain.

At the forest level, the schema master and domain naming master roles should be placed on the same domain controller as they are rarely used and should be tightly controlled. Additionally, the domain naming master FSMO should also be a global catalog server. Certain operations that use the domain naming master, such as creating grandchild domains, will fail if this is not the case.

In a forest at the Forest Functional Level Windows Server 2003, you do not have to place the domain naming master on a global catalog.

Most importantly, confirm that all FSMO roles are available using one of the management consoles (such as Dsa.msc orNtdsutil.exe).

Share this post: | | | |
Posted by sraharjo | 1 comment(s)

                                                                                                                                                                         

Suatu hari sempat ada seorang rekan saya menanyakan kepada saya, saya memiliki komputer di rumah, katanya : selain saya pake buat browsing internet, saya juga dapat menyimpan data saya di web sites tertentu, kok jaman sekarang mudah sekali ya, gratis *** menyimpan data di internet ? Kalau tiap orang di kasih space penyimpanan data sebesar 10 GB, lalu kalau yang menyimpan itu 10, 100, 1000 atau bahkan lebih dari 1 juta orang bagaimana caranya kok web tersebut masih bisa menampung ?Pertanyaan yang sederhana memang, tetapi saya sendiri tidak mudah menjawabnya, Benar juga apa yang rekan saya tanyakan, kenapa selama ini saya tidak pernah mau tau tentang hal itu, akhirnya saya dengan berat hati menjawab terhadap rekan saya tersebut, eh sory banget, saya belum bisa menjawabnya, soalnya masih abu-abu, nanti kalau saya asal jawab terus jawabannya ternyata ngawur, ya pasti saya akan merasa sangat bersalah, dan informasi yang saya berikan tidak valid secara teori dan fakta.Bermodalkan pertanyaan yang diberikan rekan saya tersebut, saya cari informasi ke sana dan ke sini, terutama informasi dari internet, nah di dapatlah satu titik terang dengan yang namanya teknologi Cloud Computing.Tapi apa hubungannya antara teknologi cloud computing dengan pertanyaan rekan saya tadi ? ternyata hubungannya memang baik-baik saja, eh salah, maksudnya hubungannya sangat erat sekali, di dalam teknologi cloud computing salah satu komponen pembangunnya adalah teknologi virtualisasi.Lalu apalagi tuch teknologi virtualisasi ? pertanyaan ini muncul dengan sendirinya dari diri saya, kok malah nyambungnya ke yang namanya virtualisasi, selama ini yang saya kenal adalah visualisasi, maklum di kantor kalau ada project apapun harus di buat dokumentasi dan hasil dokumentasi tersebut di masukkan ke dalam katagori mem-visualisasikan object, maklum saja IT katanya fisiknya tidak jelas apa yang di kerjakan, tetapi walupun banyak orang yang bilang begitu, saya tinggal tanya balik, kok kenapa IT diperlukan kalau memang tidak jelas apa yang di kerjakan? Kenapa perusahaan sampai memerlukan orang IT? Dan si user yang yang saya tanya tadi kelabakan tidak bisa menjawab.Kita lanjut lagi ke teknologi virtualisasi, pada intinya virtualisasi ini adalah mendayagunakan object fisik seoptimal mungkin untuk memberikan effort yang lebih optimal terhadap bisnis. Kalau jaman dulu kita sudah kenal dengan yang namanya VPN (Virtual Private Network), yaitu network yang berjalan di dalam network, arti sederhananya misalnya seperti ini, pada saat kita bisa terkoneksi ke internet melalui modem, maka kita menjalankan suatu applikasi dimana dengan applikasi ini seolah-olah nantinya terbentuk jalur khusus yang menghubungkan komputer kita langsung seolah-olah terhubung secara LAN dengan dengan komputer di datacenter.Nah dari teknologi simple ini, istilah dan konsep virtualisasi semakin di kembangkan oleh para pemain IT baik itu pakar IT maupun perusahaan yang bergerak di bidang IT, hasilnya sekarang kita mengenal yang namanya virtualisasi server.Virtualisasi server secara sederhananya adalah membangun server di dalam server, maksudnya begini, jika kita memiliki satu buah mesin (satu buah fisik server), maka biasanya kita hanya menginstall mesin tersebut dengan operating system tertentu dan kemudian server yang sudah terinstall operating sytem ini kita install applikasi sesuai peruntukannya, issue yang muncul jika ada banyak applikasi, kita gabung diinstall di server yang sama, maka tidak jarang terjadi bentrok applikasi dan kinerja serverpun jadi terganggu, parahnya lagi server bisa secara intermitten (tidak terduga) akan berhenti operasional secara total, wah sangat mengerikan bukan bagi kita orang IT ?Dari issue yang muncul tersebut akhirnya terjawab sudah, sekarang diciptakan yang namanya teknologi virtualisasi, pemain teknologi virtualisasi ini cukup berkembang, diantaranya adalah Microsoft Hyper-V, VMWare dan Citrix.Mengenal dan apalagi mempelajari teknologi virtualisasi merupakan suatu hal yang sangat menarik, karena teknologi ini akan menjadi platform pembangunan infrastruktur di masa depan, sebelum kita bicara lebih jauh tentang virtualisasi, kita luruskan terlebih dahulu mengenai konsep ataupun istilah cloud computing.

 

Selengkapnya dapat di download di : http://wss-id.org/files/folders/ddc/entry40576.aspx
Share this post: | | | |
Posted by sraharjo | 1 comment(s)

Suatu waktu yang sangat tidak dinanti akhirnya datang juga, hari atau tanggal yang sangat tidak saya *** sukai *** yaitu di saat software-software yang ada sudah mulai memasuki masa expired, jika penggunaan software ini ingin terus berlanjut maka mau tidak mau solusinya yaitu dengan renewal subscription, andai kata price licensi per user U$$ 100, mungkin untuk 2 user saja sich nilainya masih ok, tetapi bagaimana kalau memiliki 100 user ? artinya U$$ 100 x 100 = U$$ 10.000 , weleh weleh, itu baru satu software, belum software yang lainnya yang minta jatah renewal tahunan.

Itu pengalaman saya dahulu sebelum beralih dari citrix ke RDS (Remote Desktop Services), dari dulu memang teknologi remote application ini yang saya cari, akhirnya microsoft mengerti juga keinginan saya (entah taunya dari angin mana), maka mulai windows 2008, microsoft memperbaiki teknologi Terminal Servicenya yang sekarang berganti nama menjadi Remote Desktop Services.

Jika dulu untuk licensi citrix per user U$$ xxx , maka untuk RDS cukup U$$ xx saja, artinya bisa saya kalkulasi penghematan yang sangat signifikan, tetapi tidak mengesampingkan kehandalan services ke client tentunya, support dan service ke client tetap menjadi priority utama sebelum saya memutuskan teknologi harus di bawa ke mana.

Wal hasil, sudah setahun lamanya saya memanfaatkan teknologi RDS ini untuk handle 2 factory yang berlokasi di Jawa Barat dan Jawa Timur dengan user yang lumayan banyak yang secara simultan dan continue mengakses applikasi ERP secara remote di Head Office (Jakarta), server yang di fungsikan secara fisik cukup 2 server saja, tetapi masing-masing server fisik di dalamnya saya aktifkan roles Hypervisor (Hyper-V) untuk hosting beberapa VM (Virtual Machine), hasilnya untuk handle 20 sampai 30 user secara bersamaan dapat di handle dengan mudah dan ringan.

Untuk RD Gateway saya cukup aktifkan di salah satu fisik server, dan untuk Terminal Servicenya (RD Session Host) di aktifkan di tiap VM di mana load balancing beban di atur oleh RD Session Broker, pokoknya sangat lengkap fitur Terminal Services di Win 2008 R2 ini.

Satu lagi, teknologi hypervisor juga sudah saya terapkan untuk beberapa roles penting infrastructure lainnya, diantaranya untuk DHCP server, bayangkan saja jika suatu DHCP server yang ada di server fisik tewas, jika ganti hardware maka mau tidak mau DHCP server yang sudah authorize di Active Directory harus dibersihkan dulu supaya DHCP server yang baru ini bisa di terima di Domain, dan ini bukan perkara mudah, jika kita bangun DHCP server dengan teknologi Hypervisor yaitu under VM (Virtual Mesin), maka jangan repot-repot, cukup import DHCP server tersebut ke server lain yang sudah terinstall hypervisor, langsung up and run dalam hitungan menit saja, karena server Active Directory akan mengenali DHCP server yang di import tersebut sebagai mesin sama dengan yang tewas tadi.

Ada satu petuah dari orang bijak, anak ayam bisa kita jadikan elang jika kita bisa memperlakukannya seperi elang, artinya, OS (Operating System) apapun yang kita gunakan, asalkan kita mau explore isinya, maka akan menjadi kendaraan hebat untuk kita jadikan teman ataupun alat perang di dunia IT.

Gb. 1 Contoh Screen Capture Untuk Login ke Portal RDS :

Gb. 2 Contoh Screen Capture Remote Application yang telah di publish ke Portal RDS :

 

Demikian, semoga bermanfaat.

 

Best Regards ,

Slamet Raharjo, MVP

 

Share this post: | | | |
Posted by sraharjo | 2 comment(s)

Office Communication Server 2007 R2 Overview.

Best Regards,

Slamet Raharjo, MVP

Share this post: | | | |
Posted by sraharjo | with no comments
More Posts Next page »