ÇözümPark'a hoş geldiniz. Oturum Aç | Üye Ol
 
Ana Sayfa Makale Video Forum Resimler Dosyalar Etkinlik Hizmetlerimiz Biz Kimiz

Exchange Server

How to Exclude a Mailbox Database from Automatic Mailbox Provisioning in Exchange Server

Exchange Server 2010 ve sonrasında gelen bir özellik olan Auto Provisioning sayesinde yeni açılan posta kutuları mevcut veri tabanlarına otomatik olarak dağılmaktadır.

Yeni bir posta kutusu açmak için ister web ara yüzü ister komut setini kullanın veri tabanı belirtmeniz şart değildir.

clip_image002

clip_image003

Gerekli olan minimum bilgi isim, UPN ve şifredir.

Böyle bir durumda sistem otomatik olarak kullanıcıları mevcut DB’ lerin arasında dağıtacaktır.

Ancak sizin bazı veri tabanlarının boyutlarının gereğinden fazla büyümesi durumunda otomatik çalışan bu sistemden çıkarmak isteyebilirsiniz.

Öncelikle varsayılan durumdaki veri tabanlarının davranışını kontrol edelim

Get-MailboxDatabase | fl name,IsSuspendedFromProvisioning,IsExcludedFromProvisioning

clip_image005

Burada iki tane parametre var;

IsExcludedFromProvisioning ve IsSuspendedFromProvisioning

Aslında temelde ikisi de aynı şeyi yapmasına rağmen burada Microsoft Mühendisleri ince bir düşünce ile iki parametre kullanmışlar.

Öncelikle IsExcludedFromProvisioning parametresini kullanarak bir veri tabanı için artık yeni açılan posta kutularından herhangi birinin bunun üzerinde açılmasını engellemiş olursunuz. Yani bir nevi artık ilgili veri tabanı daha fazla kullanıcı posta kutusu kabul etmez.

Set-MailboxDatabase DB01 -IsExcludedFromProvisioning $True

Burada bir parametre daha dikkatinizi çekebilir.

IsSuspendedFromProvisioning

Bu parametre ile IsExcludedFromProvisioning parametresi aslında aynı işe yarar, yani teknik olarak ikisini de kullanabilirsiniz.

Peki aynı iş için neden iki parametre var?

Birden çok admin olan bir ortamda bazı veri tabanları geçici olarak yeni posta kutusu alımına kapatılmak istenebilir. Eğer bu işlem Exclude komutu ile yapılır ise diğer bir admin bunu false yapmaya cesaret edemez. Çünkü bir diğer admin bu veri tabanını yeni posta kutusu kabulüne kapatmış. Ancak geçici olarak kapatma durumlarını kalıcı olarak kapatma durumlarından ayırmak için suspend parametresi kullanılabilir. Bu sayede diğer bir admin aslında bu veri tabanının geçici olarak kapatıldığını anlayabilir.

Yine eğer ortamınızda birden çok admin olması durumunda veri tabanları için scope kullanmak daha mantıklı olacaktır.

Yani özellikle kullanıcı destek ekipleri gibi aslında exchange yönetimi yapmayan ama sıklıkla posta kutusu açan yöneticiler için bu veri tabanı parametresi yetkisi vermek yerine sadece ilgili adminler için ilgili posta kutusu veri tabanlarına izin verirsek aslında otomatik bir exclude yapmış oluyor.

Peki bunu nasıl yapıyoruz?

Amacımız örneğin Hakan ismindeki helpdesk uzmanın açtığı posta kutularının sadece belirli veri tabanlarında otomatik dağılmasını istiyor olabilirsiniz.

Bu senaryo gereği kullanacağımız komutlar aşağıdaki gibidir;

Öncelikle yeni bir yönetim scope oluşturuyoruz

New-ManagementScope -Name "Accounting databases" -DatabaseList "Database 1", "Database 2", "Database 3"

clip_image007

Eğer dinamik bir yapınız var ise veya çok fazla DB olması durumunda scope oluşturma işlemini filter kullanarak ta yapabilirsiniz.

New-ManagementScope -Name "Accounting Databases" -DatabaseRestrictionFilter { Name -Like '*ACCT*' }

Şimdi mevcut veya yeni açacağınız bir güvenlik grubu için scope ataması yapalım;

Yeni grup için aşağıdaki komutları kullanabilirsiniz;

Burada Security Group bölümüne mevcut bir grup ismi yazmanız veya Universal bir Group oluşturmanız gerekli.

New-ManagementRoleAssignment -SecurityGroup "Accounting Administrators" -Role "Mail Recipients" -CustomConfigWriteScope "Accounting Databases"

New-ManagementRoleAssignment -SecurityGroup "Accounting Administrators" -Role "Mail Recipient Creation" -CustomConfigWriteScope "Accounting Databases"

clip_image009

Mevcut bir role group için scope ataması için ise aşağıdaki komutları kullanabilirsiniz;

Get-ManagementRoleAssignment -RoleAssignee "Accounting Administrators" -Role "Mail Recipients" | Set-ManagementRoleAssignment -CustomConfigWriteScope "Accounting Databases"

Get-ManagementRoleAssignment -RoleAssignee "Accounting Administrators" -Role "Mail Recipient Creation" | Set-ManagementRoleAssignment -CustomConfigWriteScope "Accounting Databases"

Son olarak oluşturduğunuz veya mevcut Security Group üyelerini güncellemeniz yeterlidir.

Makalemin sonuna geldim, umarım faydalı bir makale olmuştur.

Kaynak;

https://technet.microsoft.com/en-us/library/ff628332(v=exchg.150).aspx

Tarih : 20 Mayıs 2018 Pazar 15:13 Yayınlayan: Hakan UZUNER

Yorumlar

 

Bilgehan POYRAZ

Eline sağlık Hakan hocam. Bu detayları çözümpark ailesi dışında kimsede göremeyeceğimize eminim.

Mayıs 30, 2018 00:00
 

Hakan UZUNER

Aynen hocam sadece bizde var, ÇözümPark farkı.

Mayıs 31, 2018 02:32
 

Mehmet Cakir

Hakan hocam makale için teşekkür ederim.

Aklıma takılan soru burada şu şekildedir.

DB verileri otomatik olarak db1-db2-db3 vb diye dağıtıyor diyoruz ya. Burda mantık SSD gibi uniq olarak mı veriyor?

Peki ben bu işlemi yaptım diyelim.

kullanıdığım sistemde db1 işte işçiler, db2 idari kisim, db3 müdürler, db4 yöneticiler şeklinde çalıştırıyorum diye varsayalım.

bir arkadaş geldi :) ben DB bağımsız dağıtıyorum dedi elimizdeki işte 1 yıl boyuncada DB 4 farklı database eşit dağıtıldını varsayıyorum.

yönetim karar aldı işçilere ait mailleri LAV edilsin kaldırılsın çok masraf ediyoruz ve luzumsuz dedi.

şimdi gelişi güzel dağıtılan son 1 yıllık veriler geri toplanabilir mi? toplanamaz mı?

ben burda kıyamet senaryosu yazdım ancak :)

merak ettiğim konu burda bu.

yani biz DB lerden birisi silinse göçse arıza yapsa grip olsa vs :) bu verilerin nasıl geri toplayacağız?

SSD mantığı ile çalışıyor ise bir kontrol DB vardır nereye ne koyduğunu biliyordur.

ancak burda bu mantığı ben pek çözemedim açıkması.

Makaleniz ile beraber konu hakkında bizi aydınlatacak Exchange uzmanı arkadaşlarada sorum budur:)

Belki birgün karşılaşılır bu tarz bir durumla :)

teşekkür ederim.

Temmuz 16, 2018 11:21
 

Hakan UZUNER

Merhaba, foruma sorsan daha güzel olurdu aslında. Öncelikle müdür, personel vs ayırımı aslında küçük firmalar için benim de önerdiğim bir yöntem çünkü yönetimi kolay oluyor. Pek çok bilişim uzmanı ne yazık ki PS bilmediği veya iyi olmadığı için konsola çok bağlı oysaki exchange server bd mantığı buna göre tasarlanmamıştır, hatta mimari bile böyle çalışır. Yukarıdaki makalede olduğu gibi normalde aslında doğrusu büyük yapılar ve ideal kullanım için hakan lar buraya ahmetler buraya şeklinde değil herkesi Exchange random dağıtmalı sürekli. Peki temel ayrımlar nasıl yönetiliyor? Temel ayrımlar OU bazlı aslında yönetiliyor. Bir PS hazırlıyorsunuz zamanlanmış görevlere koyup her akşam çalıştırıyorsunuz, o PS her akşam örnek müdür OU sundaki kullanıcıların kotasını müdürlere göre, çalışanların ise çalışanlara göre ayarlıyor. Biz bunu yapmak yerne müdürleri bir db ye koyıp kota belirliyoruz, sonra çalışanları ayrı db yani bu yönetim kolaylığı sağlıyor ama işletme maliyetlerini arttırıyor. SSD mantığı ne bilmiyorum açıkcası disk demek istedin herhalde, hayır öyle bir şey yok, Exchage kim nerede tutmaz çünkü bu bilgi AD de zaten var, PS ile istediğin bilgiyi çekebilirsin.

Temmuz 16, 2018 15:06
Kimliksiz yorumlar seçilemez kılınmış durumdadır.

Yazar: Hakan UZUNER

Eğitimlerim

HakanUzuner.com

Bu Kategori

Hızlı aktarma

Etiketler