Network ve Server ailesi hakkında notlarım

Virtualized Domain Controllers

2010-02-09T10:56:27Z

Eğer yapınızdaki DC’leri Hyper-V üzerinde sanal ortama taşıma düşüncesindeyseniz aşağıdaki noktalara çok dikkat etmeniz gerekli.

- Forest üzerindeki tombstone lifetime süresinden daha fazla bir süre sanal makinayı saved state duruma almayın.

-Virtual Hard Diskleri(VHD) kopyalamayın yada export etmeyin.

-Snapshot almayın.

-Disk olarak Differencing disk kullanmayın performans kaybı fazla olacaktır.

-http://technet.microsoft.com/en-us/library/dd363545(WS.10).aspx makalesinde belirtilen backup-recovery metodları dışında sanal makinanın yedeğini almayın yada restore işlemi gerçekleştirmeyin.

Aslında bunların hepsi domain üzerindeki Update Sequence Number senkronizasyonunda farklılığa sebep olabilecek noktalar.Bu sebeple en azından domain controller için bunlara dikkat etmeniz gerekli.

Benzer Yazilar:

Bu ve benzeri yazilar icin anilerduran.com'u ziyaret edebilirsiniz.

Exchange 2010 – DAG Planning

2009-12-04T12:59:00Z

Exchange 2010 üzerinde yeni High Availability çözümü olan DAG’ı http://www.anilerduran.com/index.php/2009/exchange-2010-yeni-high-availability-ozellikleri/ yazımızda incelemiştik.Organizasyonunuza DAG implemente etmek için dikkat etmeniz gereken önemli noktalara bu yazıda değinelim.

En genel gereksinimlerden başlayacak olursak
-Ortamda DNS sunucusu olmalı ve Exchange için host (A) kyıtları varolmalı
-DAG üyesi tüm exchange sunucular aynı domain üyesi olmalı
-Üzerinde hem exchange 2010 hemde directory servisi olan sunucular DAG member olamazlar
-DAG üyelerinin Exchang 2007′de olduğu gibi makina isimleri unique ve 15 karakterden az olmalı

Donanım tarafında gereksinimlere bakarsak, DAG kullanmak için spesifik bir donanım gereksinimi bulunmuyor.Planlamanızı üzerinde çalışacak rollere ve hizmet vereceğiniz kullanıcı sayısına göre planlamanız gerekiyor.Bunun için aşağıdaki linki inceleyebilirsiniz.
http://technet.microsoft.com/en-us/library/aa996719(EXCHG.140).aspx

Yazılım tarafında DAG üyesi tüm sunucular AYNI işletim sistemini çalıştırmak zorundalar.Aynı zamanda DAG cluster servisini kullanacağı için işletim sistemlerinin Enterprise sürüm olması gerekmektedir.

Network gereksinimleri kısmına biraz bakalım.
Önceki exchange versiyonlarında da her zaman best practices olarak min iki network kartına sahip olmamız istenmişti.Private kısmı cluster servisinin kullanması için(replikasyon,log shipping), public kısmı ise internal networkümüze bakan clientların ve diğer sunucuların erişimi için dedicate ediyorduk.
Exchange 2010 ile birlikte bu isimlendirme biraz değişti.Artık public private yerine MAPI ve REPLICATION networklerimiz var.MAPI clientlara hizmet veren public taraf, replication ise adından da anlaşılacağı gibi cluster hizmetinin kullanacağı private taraftır.
Aynı zamanda Exchange 2010 ile birlikte tek network üzerinden de clusterı çalıştırabilirseniz.Yalnız bu desteklenen bir konfigurasyon olmasına rağmen önerilen her zaman minumum iki network ile çalışmaktır.
Şunuda bilmenizde fayda var.Eğer MAPI network üzerinde bir fail gerçekleşirse cluster devreye girip diğer sunucudan hizmet vermeye devam edecektir.
Eğer Replication networkü fail olursa cluster servisi replikasyon için MAPI networkünü kullanmaya başlar.Replication networkü geri geldiğinde ise tekrar buradan devam eder.
Bir diğer önemli gereksinim yapıda sunucu başına kaç network kullanmaya karar verdiyseniz tüm DAG üyelerinde bu sayı aynı olmalıdır.
Eğer coğrafi bir cluster hizmetinden bahsediyorsak tüm DAG üyelerinin aralarındaki round trip network latency değeri 250 ms altına düşmemesi gerekiyor.
Bunun dışında tabi networking tarafında dikkat etmeniz gereken REPLICATION networkü üzerinde gereksiz tüm trafiği önlemektir.Bunun için DAG üyelerinde
Client for Microsoft Networks
File and Printer Sharing for Microsoft Networks
disable etmeniz gereklidir.Aynı zamanda replication network kartları kendilerini dns’e register etmemeleri gereklidir.Bunuda gene advanced ayarlarında bulunan Register this connection’s addresses in DNS ayarı ile gerçekleştirebilirsiniz.

Benzer Yazilar:

Bu ve benzeri yazilar icin anilerduran.com'u ziyaret edebilirsiniz.

Exhange 2010 – Back Pressure

2009-12-04T12:12:05Z

Exchange 2007 ile birlikte Back pressure özelliğini tanımıştık.Exchange sunucumuz belirli kaynakların yetersizliği durumunda(disk,memory vb.) gelen bağlantıları kabul etmeyip mail trafiğini durduruyordu.Hatta istersek edgetransportexeconfig dosyasını editleyerek back pressure özelliğini direk kapatabilir yada kriterleri değiştirebilirdik.

Exhange 2010 üzerinde de back pressure aynı şekilde yer alıyor.Yalnız dikkat etmeniz gereken çok çok önemli bir nokta var.Artık gelen smtp isteklerine cevap veriyor ama gelen mesajları reject ediyor.Neden buna dikkat çekiyorum?

Çünkü Exchange 2007′de bir sorun anında sunucuya bağlanıp bir smtp session başlatmayı denerdik.Eğer başarısız olursa sebebinin back pressure olabileceğini düşünebilirdik.Çünkü kaynaklar yetersizce incoming hiçbir bağlantı kabul edilmiyor.

Ama aynı şeyi 2010da düşünürsek.Diyelimki sunucu back pressure durumuna geçti ve mailler gitmiyor.Bu durumda bir smtp session başlatıp sunucu isteklere cevap veriyormu diye bakarsak verdiğini görürüz.Ancak iş mail gönderimine geldiğinde ne yazıkki bu başarısız olacaktır.

Benzer Yazilar:

Bu ve benzeri yazilar icin anilerduran.com'u ziyaret edebilirsiniz.

Exchange 2010 – Shadow Redundancy

2009-12-04T11:28:49Z

Exchange 2010 ile birlikte gelen yeni özelliklerden bir taneside Shadow Redundancy.Kısaca ne olduğundan bahsedelim.

Aslında Exchange 2007′de karşımıza çıkan güzel bir özellik vardı.Transport Dumpster.Bu özellik sayesinde cluster ortamında Hub sunucusu mailleri cluster mailbox databaselere iletirken bunu belirli retention değerlerine göre transport dumpster havuzunda tutuyordu.Böylece bir fail durumunda cluster mailbox server yapıdaki tüm HUBlardan transport dumspter içeriğini isteyerek kaybı önlüyordu.Yalnız bu özellik sadece CCR tarafında gerçekleşiyor en önemliside iki transport server arasında (HUB-HUB / HUB-EDGE) bir geri dönüş ne yazıkki sağlamıyordu.

Shadow Redundancy ise transport dumpster’ın daha kapsamlısı diyebiliriz.Shadow Redundancy enable ettiğinizde neler olduğunu aşağıdaki figur üzerinden gidelim adım adım.

A ) Bir mapi yada mobile client mesaj gönderir ve bu mesaj mailbox server rolünü tutun sunucu üzerinde tutulur.

B ) Klasik işleyiş burda da devam eder,mail submission servisi HUB sunucusunu uyararak yeni bir mail olduğunu bildirir.HUB bu maili kullanıcının outboxundan alarak kendi databaseine yazar.

C) Burdan sonra eğer alıcı aynı site içerisindeyse mail gönderilir.

D)Eğer alıcı başka bir site üzerinde ise HUB bunu başka bir transport servera atacaktır.Burada başka bir HUB sunucuda oalbilir yada yapıdaki EDGE sunuuda olabilir.

Shadow Redundancy için önemli olan transport serverların yani hopların bu özelliği desteklemesi.Hali hazırda sadece Echange 2010 sürümü bu özelliği desteklemektedir.Yani EDGE sunucuda 2010 ise aralarında Shadow Redundancy processini başlatacaklar.Bu process şöyle işlemektedir.

- HUB sunucu EDGE’e bir smtp sessionı başlatır.

-EDGE sunucu Shadow Redundancy desteklediği bilgisini geri dönüş yapar.

-HUB bunu XSHADOW komutu ile cevaplar.

-HUB mesajı EDGE’ e gönderir.EDGE bu mesajın HUB tarafından shadowlandığına dair bir işaret koyar.

-HUB da aynı şekilde EDGE’i primary server olarak görür ve shadow kuyruğuna ekler.

Bu noktadan sonra HUB sunucu mesajı silmeyecektir.Ancak EDGE tarafından discard status mesajı gelirse,yani bir sonraki hopa başarılı şekilde ulaştırdım bilgisi ulaşırsa ,o zaman bu mesajı kendi databaseinden silecektir.

Burada EDGE’in mesajı nereye gönderdiği önemli değil.Shadow Redundancy desteklemeyen bir sunucuyada gönderse o sunucudan onay bilgisini alır almaz , HUB sunucusuna discard status mesajını gönderir ve mesajı artık silebileceğini belirtir.

Eğer EDGE mesajı Shadow Redundancy destekleyen başka bir transport sunucuya atarsa yukarıdaki durum yanı şekilde EDGE ve bu sunucu arasındada gerçekleşir.

Dikkat ederseniz ortamdaki transport sunucularınızdan birisi down olduğunda yada siz bakım için offlinea aldığınızda üzerindeki mesajlar Shadow Redundancy sayesinde kaybolmuyor.Çünkü henüz mesajı iletmediği için bir önceki hop üzerinde zaten bu mesajlar tutuluyor.

Peki bu özelliği nasıl enable edeceğiz?

Grafiksel olarak Shadow Redundancy özelliğini yönetebileceğiniz bir arayüz yok.Bunun için shell komutlarını koşturmanız gerekli.

Set-TransportConfig -ShadowRedundancyEnabled $true

komutu ile Shadow Redundancy enable edilrbilir.Aynı zamanda ilgimi çeken diğer bir güzel komutta shadow altında tutulan mailler için bir age sınırı belirtebilmeniz.Default gelen ayarlarda shadowda tutulan mailler 2 gün geçtikten sonra silinir.İsterseniz

Set-TransportConfig -ShadowMessageAutoDiscardInterval 04:00:00

gibi bir komutla bunu 4 saate çekebiliriz.

Benzer Yazilar:

Bu ve benzeri yazilar icin anilerduran.com'u ziyaret edebilirsiniz.

IIS 7 Backup / Restore

2009-12-02T10:09:00Z

Bildiğiniz gibi SCCM 2007 ‘yi Server 2008 üzerine kurduğunuzda IIS 7 üzerinde birkaç konfigurasyonu gerçekleştirmeniz gerekli.Ancak tüm bileşenleri doğru yapılandırdıktan sonra SCCM tarafında sıkıntısız devam edebiliyorsunuz.Gerek SCCM upgrade senaryolarında gerekse acil durumlar için SCCM site yedeğini alabiliyoruz.Tabi bunun yanında o kadar konfigurasyonu gerçekleştirdiğimiz IIS’in yedeğinide almak faydalı olacaktır.

IIS 7′de backup ve restore işlemi oldukça kolay.Hazırlanmış olan bir scripti kullanarak aşağıdaki şekilde backup/restore işlemlerini gerçekleştirebilirsiniz.

Backup almak için;

%windir%\system32\inetsrv\appcmd.exe add backup “My Backup Name”

Backuptan dönmek için;

%windir%\system32\inetsrv\appcmd.exe restore backup “My Backup Name”

Alınan backupı silmek için;

%windir%\system32\inetsrv\appcmd.exe delete backup “My Backup Name”

inetsrv altında backup klasöründe alınan backup dosyalarınızı görebilirsiniz.

Benzer Yazilar:

Bu ve benzeri yazilar icin anilerduran.com'u ziyaret edebilirsiniz.

SCCM 2007 Build Numbers

2009-12-02T09:45:05Z

SP1 RTM     4.00.5931.0000
SP1                4.00.6221.1000
SP2 RC         4.00.6468.2001
SP2 RTM     4.00.6487.2000

Benzer Yazilar:

Bu ve benzeri yazilar icin anilerduran.com'u ziyaret edebilirsiniz.

Server 2008 üzerinde SCCM 2007 için IIS konfigurasyonları

2009-12-01T22:35:29Z

SCCM 2007′yi Server 2008 üzerinde kurmak istediğinizde on hazırlık konfigurasyonları biraz daha farklı ilerliyor.Özellikle IIS üzerinde yapmanız gereken konfigurasyonları inceleyelim.

Öncelikle Server Manager ekranından IIS bileşenini ASP.NET ile birlikte kurmanız gerekmektedir.

Kurulumun ardından Webdav 2008de gelmediği için aşağıdaki linklerden uygun versiyonu indirerek kurmanız gerekmekte.

Microsoft WebDAV Extension for IIS 7.0 (x64)

Microsoft WebDAV Extension for IIS 7.0 (x86)

Kurulumu bitirdikten sonra IIS konsolu altından WEBDAV’ı enable edelim.

Authoring ayarlarını konfigur edelim

Basic Authentication ve Windows Authenticaton rol servislerini yükleriz.World Wide Web servisini yeniden başlatırız.

Windows Authentication’ı enable ederiz.

Şimdi Default Web Site üzerinde Authorization Rules’a çift tıklayın.(Eğer bu ikonu göremiyorsanız IIS bilşenlerinden URL Authorization’ı ekleyin)

Authhorization Rules altında All users için allow izninin olduğunu doğrulayın.

Artık administrator hesabını kullanarak webdav testini gerçekleştirebiliriz.

net use * http://localhost/

Aşağıdaki gibi network path not found hatası alıyorsanız Desktop Experience Feature yüklemeniz gerekli.

The file cannot be accessed by the system hatasını alırsanız IIS Manager altında Webdav Authoring Rules altında ilgili kullanıcıyı read,write hakkı ile ekleyin.Yada authentication bölümünde
basic authentication enable edebilirsini.Tabi bu bir güvenlik riski oluşturacağından sslli kullanmanızı öneririm.
Eğer herhangi bir hata yoksa IIS 6.0 Management Compatibility role servisinide yükleyelim.

Features altından Bits Server Extensions yükleyelim.

Aynı zamanda IIS rol servislerinden ASP yüklümü mutlaka kontrol edelim.

SCCM 2007 kurulumu için IIS üzerinde temel yapılması gerekenler bundan ibaret.Artık SCCM kurulumuna başlayabilirsiniz.

Benzer Yazilar:

Bu ve benzeri yazilar icin anilerduran.com'u ziyaret edebilirsiniz.

SCCM Backup Process

2009-12-01T10:20:21Z

SCCM 2007 sitelarınızın yedeğini almak oldukça basit bildiğiniz gibi.Task altından Backup processi için bir schedule tanımlayıp yedeği başlatabiliriz.Yalnız burada alınan yedek neleri içeriyor çok iyi bilmeniz gerekiyor.Kısaca inceleyelim.

NELERİN YEDEĞİ ALINIR

- Configuration Manager Site Database ( SQL Server Database)

- Configuration Manager kurulum dizini

- Master Site Control dosyası (.\Inboxes\Sitectrl.box\Sitectrl.ct0)

- SMS ve NAL registry anahtarları

NELERİN YEDEĞİ ALINMAZ

Yedekleme işlemi sırasında SCCM kurulum dizinindeki logların yedeği alınır fakat diğer dizinlerde bulunan log dosyalarının yedeği alınmaz.Bunun için alternatif bir metod bulmanız gerekli.
SQL Server üzerindeki master database yedeğinin alınmasına gerek yoktur.Bu olmadanda restore işlemini yapabiliriz.
Site backup process’i sırasında CONFIGMGR clientların yedeği alınmaz.

Benzer Yazilar:

Bu ve benzeri yazilar icin anilerduran.com'u ziyaret edebilirsiniz.

SCCM R2 ile SQL Server Reporting Services Entegrasyonu

2009-11-27T11:05:51Z

System Center Configuration Manager 2007 R2 sürümü ile birlikte gelen yeniliklerden bir taneside SQL Server Reporting Services ile artık tümleşik çalışabilmesi.

SCCM altında raporlamaları kendi bünyesindeki report servisinden gerçekleştiriyorduk.Uzun zamandır SQL Server reporting kullananlar sccm kosnolu altında raporlarla uğraşırken bazı zorluklar yaşayabiliyordu.Artık birbirine entegra biçinde çalışan bu iki servisten en verimli şekilde faydalanabilecekler.

Bunun dışında bu noktada en beğendiğim özelliklerden biriside , Sql Reportin Servisi altında raporlar için mail tasklar oluşturabiliyorum.Yani rapor oluştuğunda smtp servisini kullanarak yöneticiye mail atabilmesini sağlayabiliyorum.Eğer SCCM de de SQL Reporting servisini kullanarak custom rapolar oluşturursanız bu tarzda bir notification belirleyebilme şansınız var.

Yalnız bu entegrasyonu kullanabilmek için birkaç ön gereksinim var.İsterseniz yapılması gerekenleri adım adım inceleyelim.

1 ) Öncelikle yapınızda kullanıdığınız SQL Server için reporting service i yüklemiş olmanız gerekiyor.Eğer ilk kurulum sırasında bu işlemi gerçekleştirmediyseniz istediğiniz zaman kurulum DVDsini takarak ilgili bileşeni kurabilirsiniz.

2) Aynı zamanda bu bileşen üzerinde birkaç ayar gerçekleştirmeniz gerekli.Bunun için

Microsoft SQL Server 2005 / Conffiguration Tools altında Reporting Services Configuration konsolu açılır.

Report Server Virtual Directory ekranında New ile Default Web Site üzerinde ReportServer isimli bir virtual directory oluşturulur.

Report Manager Virtual Directory altında New ile Default Web Site üzerinde Reports isimli bir virtual directory oluşturulur.

Database Setup bölümünde Reporting Services sunucusu seçilerek connect tıklanır.

Database Connection sayfasında Configure Report Server bölümünde New ile yeni bir database oluşturulur.

Ve email settings kısmında oluşturulan custom raporlar için email subscriptionları oluşturabilirsiniz.

Tüm bunların dışında SCCM tarafında da bu servisi kullanmak için yapmanız gereken ufak bir konfigurasyon var.

Site Database / Site Management / Site code / Site Settings / Site Systems altında inerek New ile yeni bir rol ekleme sihirbazını açarız.Bu kısımda seçmeniz gereken rol Reporting Services point dir.

Artık Report containeri altında Reportin Service isimli yeni bir container göreceksiniz.Bu kısımda sağ klik create reports ile SQL tabanlı raporları tabledan çekerek oluşturabilirsiniz.

Benzer Yazilar:

Bu ve benzeri yazilar icin anilerduran.com'u ziyaret edebilirsiniz.

Windows Update Agent Version Check

2009-11-27T10:47:12Z

Configuration Manager 2007 clientların WSUS üzerinden gerekli olan update listesine ulaşabilmeleri için üzerinlerindeki Windows Update Agent (WUA) versiyonunun 3.0 olması gerekiyor.Bu versiyon bilgisini görüntülemek için iki yöntem kullanabilirsiniz;

1)Software Updates Report kullanarak

Configuration Manager konsolu altında Site Database / Computer Management / Reporting /Reports dizininde Scan1- Last Scan States by collection raporu çalıştırılır.Rapor altında Windows Update Agent Version bölümünde versiyon bilgisi görüntülenebilir

2) Resource Explorer kullanılarak

Yine Configuration Manager konsolunda Site Database / Computer Management / Collections altında ilgili clientları barındıran collection için resource explorer çalıştırlır.Hardware bölümünde aynı şekilde Windows Update Agent Version bölümü incelenebilir.

Benzer Yazilar:

Bu ve benzeri yazilar icin anilerduran.com'u ziyaret edebilirsiniz.