Network ve Server ailesi hakkında notlarım

How to Use the Shell to enter the product key on Exchange 2010

Set-ExchangeServer -Identity ExServer01 -ProductKey aaaaa-aaaaa-aaaaa-aaaaa-aaaaa

Outlook 2003 – Exchange 2010 Connection Issues

Tüm yapıyı Exchange 2010′a taşıdığımızı düşünelim.EÄŸer yapınızda Outlook 2003 clientlar bulunuyorsa;

Cannot start Microsoft Office Outlook. Unable to open the Outlook window. The set of folders could not be opened.

Unable to open your default e-mail folders. The Microsoft Exchange Server computer is not available. Either there are network problems or the Microsoft Exchange Server computer is down for maintenance.

The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action.

Unable to open your default e-mail folders. The information store could not be opened.

Outlook could not log on. Check to make sure you are connected to the network and are using the proper server and mailbox name. The connection to the Microsoft Exchange Server is unavailable. Outlook must be online or connected to complete this action.

Aslında bu hataların sebebi Exchange 2010 ile birlikte CAS ile Mailbox arasındaki bağlantıların RPC üzerinden encrypt edilmiş bir şekilde gerçekleşmesidir.Outlook 2007 yada 2010 üzerinde zaten RPC default olarak şifrelenmiş gittiği için bir sıkıntı söz konusu değil.Ancak Outlook 2003 üzerinde

encryption bölümünün yukarıdaki gibi işaretli olması gerekmektedir.

Tabiki tüm clientlarınız outlook 2003 ise migration işleminden sonra tek tek profilleri dolaşmanız mümkün bir senaryo olmayacaktır.Bu yüzden diğer bir metod olarak geçici bir süre aşağıdaki komut ile CASlar üzerindeki encryptionu disable edebilirsiniz.

Set-RpcClientAccess –Server Exchange_server_name –EncryptionRequired $False

DAG – CAS Array Trick

Exchange 2010 üzerinde CAS Array oluÅŸturmayı düşünüyorsanız ÅŸu bilgiyi mutlaka göz önünde bulundurmanız gerekli.Aynı sunucu üzerinde NLB ve Failover Clustering kullanamıyorsunuz.Yani Bir sunucu üzerinde mailbox rolünü kurup bunu DAG üyesi yaptıysanız , aynı sunucuya CAS’da kurabilirsiniz ama bu CAS’ı NLB kullanarak CAS Array’ine alamazsınız.
Microsoft burada external bir load balancer kullanmanızı öneriyor.

Multiple Forest için AutoDiscover konfigurasyonu

Exchange 2010 üzerinde bulunan AutoDiscover servisi sayesinde;

-Microsoft Outlook 2007 yada daha üstü MAPI clientların otomatik konfigurasyonlarını gerçekleştirebilir,
-Microsoft Outlook 2007 yada daha üstü MAPI clientlar ile Exchange özelliklerine erişim verebilir,
-Mobile 6.1 ve daha üstü Mobile işletim sistemlerini aynı şekilde username-password ikilisi ile otomatik konfigure edebiliriz.

Yani kısacası domaindeki bir kullanıcının outlook konfigurasyonu sırasında aslında birşey yapmasına gerek kalmıyor.Domain username ve passwordu kullanılarak AutoDiscover servisi ile birlikte otomatik Outlook konfigurasyonu gerçekleşebiliyor.

Benim bu yazıda deÄŸinmek istediÄŸim nokta farklı.Bir migration iÅŸlemi düşünelim.Yapınızda çalışan Exchange 2003 yada Exchange 2007 var ve siz Exchange 2010′a geçiÅŸ düşünüyorsunuz.EÄŸer forestınız aynı kalacak ise sıkıntılarınız oldukça az.Ama bu geçiÅŸ sırasında farklı bir forest kullanacaksanız o zaman birçok noktayı göz önünde bulundurmanız lazım.Bunlardan biriside geçiÅŸ iÅŸlemi boyunca her iki yapınında çalışır vaziyette olması.Yani siz kullanıcıların yarısını yeni yapıya geçirdiÄŸinizde,eski yapıdakilerde yeni yapıdakilerde mail flow iÅŸleminde sıkıntı yaÅŸamamaları gerekir.

Burada birçok kriter var aslında üzerinde düşünümesi gereken.Bunlardan biriside Autodiscover konfigurasyonu.Diyelimki bir kullanıcıyı ADMT ile diğer foresta aldınız.Aynı zamanda cross forest migration için Exchange üzerinde move-request komutunu kullandınız.Buraya kadar sıkıntı yok.Ama her iki taraftaki kullanıcılarında diğer CASlardaki Autodiscover servisine erişmesini istiyorsanız AutoDiscover için Multiple forest konfigurasyonu yapmanız gerekiyor.

Ancak bu sanıldığı kadar zor bir işlem değil.Tek yapmamız gereken kaynak forest üzerinde

$a = Get-Credential
Export-AutoDiscoverConfig -DomainController -TargetForestDomainController -TargetForestCredential $a -MultipleExchangeDeployments $true

komutlarını girmek.Bu komutlarla birlikte kaynak foresttaki CAS üzerindeki service pointler(SCP) hedef exchange için güncellenecektir.Böylece iki taraftaki clientlarada Autodiscover hizmeti verebilecektir.

Exchange 2010 CAS Proxying

Exchange 2010 CAS rolündeki en önemli noktalardan birisi RPC üzerinden iletiÅŸimdir.Exchange 2003′de front end sunucular back end ile http üzerinden haberleÅŸiyorlardı.Ancak Exchange 2010 CAS rolüne sahip sunucu Mailbox rolünü sahip sunucu ile RPC üzerinden haberleÅŸiyor.Burada tümleÅŸik gelen hoÅŸ bir öelliÄŸimiz var.Proxying.

Exchange 2010 CAS sunucuları diÄŸer CASlar için proxy görevi görebiliyor.Biraz daha açıklama gerekirse birden fazla sitedan oluÅŸan bir yapımız var.Her site içerisinde de CAS sunucularımız.Ancak bu CASlardan sadece bir tanesi internet’e bakıyor.Bu durumda bu CAS üzerine gelen baÄŸlantılar otomatik olarak ilgili site üzerindeki CAS sunucuya aktarılıyor.Buna kısaca CAS-CAS proxying diyoruz.

Aynı senaryo Exchange 2007 CAS olan ortamlarda da uygulanabilir.Böylece upgrade senaryolarında Exchange 2007 ve Exchange 2010 coexist şekilde çalışabiliyor belli bir süre boyunca.

CAS Proxying sırasında arka planda nelerin gerçekleştiğini bilmemiz bizim için önemli.Outlook Web App üzerinden bir bağlantı isteği geldiğinde sırasıyla;

- Bağlantıyı karşılayan CAS sunucusu Active Directory üzerinde bir sorgu göndererek kullanıcının mailbox location bilgisini ve Mailbox serverın versiyon bilgisini elde eder.
-EÄŸer hedef mail sunucu Exchange 2003 ise fakat kullanıcı /exchange ile bu directory’e ulaÅŸmışsa otomatik olarak bu sunucuya proxy ediliyor.
-EÄŸer hedef mail sunucu Exchange 2010 ise ve farklı bir active directory altında yer alıyorsa otomatik olarak bu active directory site’ı üzerinde bulunan CAS sunucusuna istek proxy edilir.Yalnız burada CAS ‘ın InternalURL ve ExternalURL bilgileri kullanılır.EÄŸer externalurl bilgisi girilmiÅŸ ise client bu adrese,eÄŸer girilmemiÅŸ ise client otomatik olarak internalurl adresine proxy edilir.

InternalURL değeri Exchange 2010 kurulumu sırasında otomatik olarak belirtilir ve mutlaka yapınıza göre değiştirmeniz gereken bir adrestir.ExternalURL ise kurulum sırasında opsiyonel olarak yada kurulumdan sonra konsol veya powershell ile set edilebilir.

ADMT için kaynak-hedef domain ön gereksinimleri

ADMT ile migration işlemini gerçekleştirmeden önce uzun bir planlama dönemi gerekiyor.Bu planlama fazlarından biriside kaynak ve hedef domainlerin migration için gerekli ön gereksinimlere sahip olması.Burada toplam 3 adet ön gereksinimden söz edebiliriz.

- Kaynak domain üzerinde domain$$$ isminde bir local grup oluşturmanız gerekli.Buradaki domain ismi sizin domainizin netbios ismi olmalıdır.Aynı zamanda bu gruba hiçbir üye atamayın

- Kaynak PDC Emulator üzerinde 

HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Control\LSA\TcpipClientSupport deÄŸerini 1 ‘e çekin.

- Kaynak ve hedef domain üzerinde default domain controller policy içerisinde yer alan Audit Account Management policysini Success ve Failure için enable hale getirin.

Failed to change domain affiliation

ADMT ile cross forest migration projelerini gerçekleştirirken official ADMT guidelarında rastlayamayacağınız bir problemle karşılaşabilirsiniz.2008 yada 2008r2 üzerindeki bir computer hesabını başka bir forest altına aktarırken pre-check kısmını sorunsuz geçiyoruz.Ancak ADMT client computer hesabına agent kurulumunu gerçekleştirdikten sonra

ERR3:7075 Failed to change domain affiliation, hr=800704f1 The system detected a possible attempt to compromise security. Please ensure that you can contact the server that authenticated you.

hatasını size sunabiliyor.Aslında ADMT ile bir migration yapıyorsanız alınan hataların çok büyük bir bölümü dns yada firewall tarafındadır.Ancak yukarıdaki sorunun bunlarla bir ilgisi yok.Yukarıdaki sorunu geçebilmemiz için hem source hem target domain controller policyleri üzerinde aÅŸağıdaki makalede belirtilen policy’nin enable olması gerekli.

http://support.microsoft.com/kb/942564

Bu ince trick sizi uzun zaman kaybından kurtaracaktır.

Virtualized Domain Controllers

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.

Exchange 2010 – DAG Planning

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.

Exhange 2010 – Back Pressure

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.

Exchange 2010 – Shadow Redundancy

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.

IIS 7 Backup / Restore

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.

SCCM 2007 Build Numbers

SP1 RTM     4.00.5931.0000
SP1                4.00.6221.1000
SP2 RC         4.00.6468.2001
SP2 RTM     4.00.6487.2000

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

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.

SCCM Backup Process

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.

SCCM R2 ile SQL Server Reporting Services Entegrasyonu

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.

Windows Update Agent Version Check

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.

Windows Server 2008 R2 üzerinde Exchange 2007 desteği

BildiÄŸimiz gibi Windows Server 2008 R2 üzerine Exchange 2007′yi SPli dahil kuramıyoruz.R2 ile birlikte ancak Exchange 2010′un destekleneceÄŸi duyurulmuÅŸtu.

Yalnız müşterilerden alınan feedbackler doğrultusunda yakın zamanda çıkarılacak bir update paketi ile Server 2008 R2 üzerine Exchange 2007 desteklenir hale gelecek.İlgili msexchangeteam duyurusunu aşağıdaki adreste bulabilirsiniz.

http://msexchangeteam.com/archive/2009/11/04/453026.aspx