Cloud Sloutions

Bulut Çözümleri

Read more

Training Services

Eğitim Hizmetleri

Read more

System Center Solutions

System Center Çözümleri

Read more

Office365 – Forest Migration – Part1

No Comments

 

Merhaba ,

Bu makalede office365 ile entegre olan onpremise de bulunan active directory yapısının yeni forest’a taşınma işlemleri ve dikkat edilmesi noktalar anlatılacaktır.  Microsoft platformu ile çalışan, active directory, exchange ve benzeri ürünlerin kurulumunu ve yönetimini yapan herkes mutlaka migration durumları ile karşılaştı. Şirket evlilikleri,kaynak paylaşımları,ölçeklendirmeler,iyileştirmeler bunlara birkaç örnek. Bildiğiniz gibi birden fazla migration türü var, Cross-forest, Interforest ve Intraforest migration şeklinde sıralayabiliriz. Bulut teknolojilerinin yaygınlaşması ile birlikte artık şirketler yavaş yavaş lokalde kullandığı birçok servisi cloud tarafında  SaaS,PaaS ve Iaas olarak kullanmaya başladı. Bu servislere gün geçtikçe yenisi eklenerek XaaS(anything as a service) , BaaS(Backup as a Service) ve DraaS(Disaster Recovery as a Service) şeklinde ilerlemeye ve bilişim dünyasında hızla yer almaya devam ediyor. Vendor lar ve özel şirketler dahil olmak üzere kendi bulut sistemlerini oluşturarak (private cloud  değil 🙂 ) tam otomatize bulut çözümleri üreterek yönetilen hizmetler ile birlikte servis sağlamaya başladı. Geleneksel mimarilerin değiştiğini ve bu değişimleri karşılamak gerektiğini software-defined teknolojilerle farketmeye başladık, Üreticilerin nerdeyse hepsi kendi ürünlerini piyasaya sürdü bile. Nsx,Viptela,Vsan,Proxmox ceph karşılaştığımız,projeleri içerisinde yer aldığımız ve ya projelendirdiğimiz ürünler olmuştur. Software-defined geleneksel yapıdan modern yapılara geçiş süreci fazlası ile göze çarpıyor. Şuan da yaygın olarak kullanılan office365 ile birlikte hybrid ve ya cutover geçişlerde karşılaşılan problemlere ve adımlarına olabildiğince değinmeye çalışacağım.  Bu makalede aslında ne kadar azure ad connect ve exchange online servislerinin yeni active directory ortamına entegrasyonundan bahsedecek olsakda etki alanı değişiklikleri lokalde çalışan tüm bağımlı servisleri ve platformları etkileyen riskli ve ciddi analizler gerektiren süreçlerdir. Bu geçişler yapıların büyüklüğüne göre günleri ve ayları bulabilir. Migration türlerinden bahsetmişken kısaca migration türlerini hatırlayalım.

arch

Interforest Migration

Bu migration türünde amaç forest içerisinde organizasyonları bir arada tutarak tüm organizasyonların birbirinin kaynaklarına erişmesini sağlamaktır. Bu demek oluyor ki kaynak domain ortamdan kaldırılmıyor.  Eski ortamınıza her daim geri dönebilme şansınız var.

Intraforest Migration

Bu migration türünde amaç forest yapısını ve yönetimi konsolide ederek tek etkialanı üzerinde ilerlemek, Bir nevi kaynak etkialanında bulunan objeler hedef etkialanına taşınacak ve kaynak domaine bir daha erişim sağlanmayacaktır.

Migration consideration Interforest restructure Intraforest restructure
Object preservation Objects are cloned rather than migrated. The original object remains in the source location to maintain access to resources for users. User and group objects are migrated and no longer exist in the source location. Computer and managed service account objects copied and the original accounts remain enabled in the source domain.
Security identifier (SID) history maintenance Maintaining SID history is optional. SID history is required for user, group, and computer accounts, but not managed service accounts.
Password retention Password retention is optional. Passwords are always retained.
Local profile migration You must use tools such as ADMT to migrate local profiles. Local profiles are migrated automatically because the user’s globally unique identifier (GUID) is preserved.
Closed sets You do not have to migrate accounts in closed sets. For more information, see Background Information for Restructuring Active Directory Domains Within a Forest (http://go.microsoft.com/fwlink/?LinkId=122123). You must migrate accounts in closed sets.

Cross-Forest Migration

Bu migration türü exchange ortamında bulunan mailbox’ların diğer forest ta bulunan exchange ortamına taşınmasını gerektiren durumlarda olur ve yukarıda bahsetmiş olduğumuz intraforest ve ya interforest yapısını gerektirir.

crossforest

Benim kurgulayacağım senaryoda olddomain.local( kaynak domain olarak bahsedilecek) den newdomain.local(hedef domain olarak bahsedilecek) e hesaplar taşınıp Office365 te bulunan hesaplara tekrar bağlanıp hedef domaindeki yerel hesapları kullanarak MFA(Multi-factor Authentication) ile office365 servislerini kullanmaları amaçlanmıştır.

 

Test Ortamında;

Office365 tenant – canbolat-tr.com

DC – dc01.olddomain.local

Azure ad Connect – azuread01.olddomain.local

Client- client01.oldomain.local

DC- dc02.newdomain.local

Azure Ad Connect – azuread02.newdomain.local

Client- client02.newdomain.local

Migration tool – Questtool.newdomain.local

Migration tool olarak Microsoft ADMT de kullanabilirsiniz. Ben migration geçişlerinde Quest’i tercih ediyorum. Quest te daha advanced bir ürün olması birlikte objelerin geçişleri ve sürecin yönetilmesi konusunda daha esnek çözümler sağlıyor, Makalenin ilerleyen serilerinde sid,objectguid,immutable id gibi kavramlardan sıkça bahsdeceğiz.

Esxi 6.0 , Vcenter 6 , Storwize v3700 , Ha konfigürasyonu,Networking ve Lacp konfigürasyonu

No Comments

Merhaba , bu makalede Esxi 6.0 , Vcenter 6 , Storwize v3700 , Ha konfigürasyonu,Networking ve Lacp konfigürasyonlarından bahsedeceğim.Öncelikle NOVATEK ailesine bu demo ortamı için teşekkür ederim.Faydalı olması dileğiyle.

Dokümanın altında “full screen” simgesine tıklayarak tam erkanda görüntüleyebilirsiniz.

Netmask ; Maximum Subnet Hosts değerleri

No Comments

Netmask Address Prefix Length Hosts / Class C’s / Class B’s / Class A’s
255.255.255.255 /32 1
255.255.255.254 /31 2
255.255.255.252 /30 4
255.255.255.248 /29 8
255.255.255.240 /28 16
255.255.255.224 /27 32
255.255.255.192 /26 64
255.255.255.128 /25 128
255.255.255.0 /24 (Class C) 256 / 1
255.255.254.0 /23 512 / 2
255.255.252.0 /22 1,024 / 4
255.255.248.0 /21 2,048 / 8
255.255.240.0 /20 4,096 / 16
255.255.224.0 /19 8,192 / 32
255.255.192.0 /18 16,384 / 64
255.255.128.0 /17 32,768 / 128
255.255.0.0 /16 (Class B) 65,536 / 256 / 1
255.254.0.0 /15 131,072 / 512 / 2
255.252.0.0 /14 262,144 / 1024 / 4
255.248.0.0 /13 524,288 / 2048 / 8
255.240.0.0 /12 1,048,576 / 4096 / 16
255.224.0.0 /11 2,097,152 / 8129 / 32
255.192.0.0 /10 4,194,304 / 16,384 / 64
255.128.0.0 /9 8,388,608 / 32,768 / 128
255.0.0.0 /8 (Class A) 16,777,216 / 65,536 / 256 / 1
254.0.0.0 /7 33,554,432 / 131,072 / 512 / 2
252.0.0.0 /6 67,108,864 / 262,144 / 1,024 / 4
248.0.0.0 /5 134,217,728 / 524,288 / 2,048 / 8
240.0.0.0 /4 268,435,456 / 1,048,576 / 4,096 / 16
224.0.0.0 /3 536,870,912 / 2,097,152 / 8,192 / 32
192.0.0.0 /2 1,073,741,824 / 4,194,304 / 16,384 / 64
128.0.0.0 /1 2,147,483,648 / 8,388,608 / 32,768 / 128
0.0.0.0 /0 (The Internet) 4,294,967,296 / 16,777,216 / 65,536 / 256

0 – 256 Hosts or Subnets
128 – 128 Hosts or Subnets
192 – 64 Hosts or Subnets
224 – 32 Hosts or Subnets
240 – 16 Hosts or Subnets
248 – 8 Hosts or Subnets
252 – 4 Hosts or Subnets
254 – 2 Hosts or Subnets
255 – 1 Host or Subnet

Backup Academy Certified Professional

No Comments

Veeam ile uğraşanlar bilir, veeam sadece yedekleme ürünü olarak lanse edilsede , son zamanlarda yedekleme ürününden fazlası haline geldi , disaster recovery planlamasında vazgeçilmez ürünlerden biri.Sanallaştırma platformları ve backup stratejileri konusunda kendinizi sınamak ve geçerli bir sertifika almak istiyorsanız www.backupacademy.com adresinden online olarak sınava girip başarılı olmanız halinde ücretsiz olan bu sertifikaya sahip olabilirsiniz.

image

Fortigate 60 D ve Draytek 2760 üzerinde ipsec vpn kurulumu

No Comments

Merhaba , bu makalede fortinet ve draytek cihazları arasında ipsec vpn yapılandırmasıdan bahsedeceğim.Vpn,noktadan noktaya güvenli bir şekilde bağlanmanızı sağlar.Birden fazla vpn metodu mevcuttur,pptp ,lt2p/ipsec,ssl vpn sahada en çok karşılaşılan vpn türleri olarak karşımıza gelmekte.Ipsec vpn neden kullanılır diye düşünürsek şubelerinizi biribirine bağlamak ve ya şubenizi merkeze bağlamak için ipsec kullanırsınız.Ipsec layer 3 katmanında çalışır , yani uygulama bağımsızdır.Vpn ipsec destekleyen tüm network cihazlarınızla kurulum yapabiliyorsunuz.Ipsec vpn dezavantajı olarak cihaz üzerinde aşırı bir cpu yükü (trafik üzerinde encryption,decryption ve uyumsuzluk sorunları) farklı ürünlerle ipsec vpn yaparken problem yaşayabiliyorsunuz,(phase1 ve phase2’nin stabil olamaması gibi.)Bunun dışında ipsec vpn size ; kimlik doğrulama,veri bütünlüğü,doğruluğu ve gizliği sağlar.Verilerinizi kapsulleyerek bir tünelleme yoluyla noktadan noktaya güvenilir bir şekilde ulaştırır.

Senaryoda bir adet fortigate 60d ve draytek 2760 ürünleri arasında ipsec vpn kurulumu yapılandırılacak ve merkez kaynaklarına erişim sağlanacak.

Fortigate 60 D v5.2.1,build618 (GA) – Merkez ofis – local subnet 192.168.1.0/24 ( kullanıcı ve cihaz sayısı fazla olmadığı için subnet yeterli , büyük yapılarda ciddi bir subnet hesaplaması gereklidir.Böyle bir network de en fazla 254 cihaza ip sağlayabilirsiniz.

Draytek 2760 ver 3.7.5.4 – şube – local subnet 10.0.1.0/24

Şunu da belirtmek istiyorum , ürünlere ve tercihlere göre bir çok kurulum ve konfigurasyon olabilir.Fortigate ve draytek arasında saha deneyimlerime göre en stabil olduğunu düşündüğüm kurulumu yapacağım.

Öncelikle draytek tarafında kurulumu yapacağım.

Draytek web gui üzerinde “vpn and remote acess”bölümüne gelip, “lan to lan” sekmesine geliyoruz.profile bölümünde boşta olan ve ya ilk sıradaki 1.profile tıklıyoruz.

draytek1

İp security method kısmında “3des with authentication” ı seçip “advanced”kısmına geliyoruz.

draytek2

Mode olarak aggressive mode’u seçtikten sonra phase1 ve phase2 kısımlarını tanımlıyoruz.Bu kısımlar önemlidir.Phase1 kısmında hem draytek tarafında hem de fortigate üzerinde iki adet proposal tanımlayacağız.Phase2 kısmında tek proposal kullanacağız.

Key life time değerleri iki tarafda da aynı olmak zorunda.

draytek3

3.Dial-in settings kısmında dial-in type kısmında Ipsec tunnel i işaretliyip,diğer tanımları kaldırıyoruz.Eğer bu kutucukları dolu bırakırsınız sizden pptp yapılandırmasınıda isteyecektir.Tcp/ip network settings kısmında remote network ip tanımı olarak fortigate cihazında tanımlı olan internal local subnet tanımı yapıyoruz.Bu adres fortigate cihazınızın internal interface kısmı.Ok diyerek ilk konfigurasyonu tamamlıyoruz.

Vpn and remote access kısmında bu sefer “ipsec general setup ” bölümüne geliyoruz.

draytek4

Lan to lan bölümünde ike authentication method olarak kullandığımız aynı pre-shared key i aynı şekilde buraya yazıyoruz. Esp ksımında des 3des ve aes kutucuklarını işaretliyoruz.Ok diyerek işlemi tamamlıyoruz.Draytek tarafında kurulum bitti.Fortinet tarafına geçiyoruz.

Fortigate 60 D üzerinde vpn sekmesine geçmeden önce local subnet ve remote subnet tanımlarını yapmamız gerekiyor.Bu tanımları daha sonra vpn için kural yazarken kullanacağız.

draytek5

Local ve remote subnet yani merkez ve şube subnet tanımlarını yaptıktan sonra ipsec vpn kurulumuna başlayabiliriz.Vpn sekmesine gelip ipsec–>tunnel–>create new diyerek yeni vpn profili oluşturuyoruz.

fortigate1

Fortigate burada bize hazır birçok config template sunuyor.İpsec yapacağınız cihaza göre template seçebilirsiniz.Bu templateler içerisinde phase1,phase2 ,diffie hellman group tanımları otomatik olarak gelmekte.Şuan da draytek için bir template yok bu yüzden maneul oluşturmak zorundayız.Profil için belirleyici bir isim yazıp “costum VPN tunnel(no template) ” seçip,ilerliyoruz.

fortigate2

Remote gateway  : Static ip address

Ip address : Draytek wan ip adresini yazıyorum.

fortigate3

Bu kısım önemli pre-shared key tanımına draytek üzerinde tanımladığımız şifreyi yazıyoruz.Mode olarak “aggressive” olmalı,draytek üzerinde lan to lan kısmında da modu aggressive olarak ayarlamıştık.Peer options kısmında any peer id olarak bırakıyoruz.

fortigate4

Phase1 bölümünde propsal encryption tanımlarımızı yapıyoruz.Draytek üzerinde 2 adet encryption tanımlayacağız demiştik. Diffie hellman group olarak “2” yi seçiyoruz.Draytek cihazlarda bu grup varsayılan olarak 2 dir. Key life time değerlerininde iki tarafda aynı olması gerektiğini söylemiştik.

fortigate5

Phase2 bölümünde lokal ve şube subnet tanımlarını yazıyoruz.Phase 2 proposal bölümünde tek encryption belirleyeceğiz demiştik.Draytek tarafında phase2 kısmında bu şekilde tanımlamıştık.Aynı şekilde key lifetime değerleride draytek üzerindeki değerlerle aynı olmalı.

İpsec kurulumu tamamlandı,şimdi sırada vpn için static route ve vpn policy tanımlamamız gerek.

fortigate6

Static route ile şube network ‘ünden gelen herhangi ip “device”kısmında ipsec vpn ile oluşturmuş olduğumuz vpn profilinden yararlanarak local subnet e yönlendirilmiş olacak.

fortigate7

ipsec vpn için lokal subnet ten remote subnet e yani merkezden şubeye ve aynı şekilde şube den merkez network e erişim için policy tanımlaması yapıyorum.Böylece ipsec vpn kurulumu tamamlanmış oluyor.İpsec monitore gelerek vpn durumunu kontrol edelim.

fortigate8

Draytek tarafında vpn durumunu kontrol edelim.

draytek6

İki taraftada ipsec vpn bağlantımız stabil görünüyor.Başka bir makalede görüşmek üzere.

Symantec Backup Exec -Virtual Machine Backup- Backup Exec failed to connect to one or more virtual machines problemi ve çözümü

No Comments

Merhaba bu yazımda , Symantec Backup Exec ile virtual infrastructure agent backup alırken yaşanan bi sorun ve çözümünden bahsedeceğim.

Symantec Backup Exec , piyasada yaygın olarak kullanılan bir yedekleme çözümüdür.Bir çok yazılım gibi backup exec’de compression ve deduplication özelliklerini kullanıyor.Sanallaştırma artık çağımızın vazgeçilmez teknolojileri arasında,İş sanallaştırma olduğu zaman durum biraz daha değişiyor.Kullanılan yazılımlar , disaster recovery planlamaları , rpo ve rto süreleri gibi.Sanal platfromda artık kendini ispatlamış ve liderlik eden başlıca backup yazılımları var,başta gelenler Veeam , DoubleTake,Acronis ve alternatif birçok vendor bulabilirsiniz.

vc1

Symantec Backup Exec ‘de bare metal hipervizor katmanı üzerinde çalışan sanal makinaların guest ve ya vm olarak tabir edilen sunucuların yedeklerini alabiliyor.Sanallaştırmanın hayatımıza girmesiyle backup exec sanal platformlar için yedek alabilme özelliğini geliştirdi.Yaygın olarak kullanılan hyper-v,esxi ve birçok vendor için destek veriyor.Bunun için kullandığınız hipervizor platformu için lisans alıyorsunuz.Vmware platformu için “Agent for VMware Virtual İnfrastructure ” almanız gerekli.Virtual İnsfrastructure lisansı multi-esxi ve cluster yapılarınız var ise kullanmanız gereken bir lisans,Lisanslama ve özellikler konusunda daha detaylı bilgiye buradan ulaşabilirsiniz.

licensed

Backup Exec üzerinde gerekli tanımlamaları yaptık ve job’ı oluşturduk.

vc

Job çalıştı ve backup işlemi bittikten sonra aşağıdaki gibi bir hata ile karşılaştınız.Aslında sorunun çözümü çok basit ve aşağıda belirtmiş durumda.

(Server: “BACKUPSRV01”) (Job: “Corporation_VM_FullBackup “) The job completed successfully. However, the following conditions were encountered: Backup Exec failed to connect to one or more virtual machines and was unable to collect the necessary metadata to restore individual application items. You cannot perform GRT-enabled restores of application data from this backup. You must install the Agent for Windows and the virtual machine tools provided by your host software on the virtual machine.

Oluşturmuş olduğunuz job üzerinde GRT’yi etkinliştirmekten ve gereksinimleri yerine getirmemekten kaynaklanıyor.

grt

GRT nedir ondan bahsedecek olursak Granular Recovery Technology , almış olduğunuz backup içerisinden item level olarak yani obje bazlı geri dönme işlemi yapabiliyorsunuz.Örnek olarak bir exchange database’in içerisinden tek bir mail i dönmek gibi.Backup Exec ‘de aldığı vmdk ve ya vhd (kullanmış olduğunuz platform’a göre) grt ile alınan backup içerisinden obje bazlı kurtarma işlemi yapabiliyor.GRT desteklediği servisleri yukarıda da belirtmiş ;

  • Microsoft Active Directory

  • Microsoft Exchange Server

  • Microsoft SharePoint

  • VMware

  • Hyper-V

GRT ile ilgili detaylı bilgiye buradan ulaşabilirsiniz.

Eğer GRT’yi etkinleştirmeseydiniz bu hatayı almış olmayacaktınız.Bu problemide giderebilmek için her sanal sunucu için agent kurulumu yapmanız gerekli

1)Backup Exec Agent

2)Vmware için Vmware Tools   , Hyper v için ise Integration Services

Virtual machine backup dışında item level olarak backup almak için zaten bu bileşenleri kuracaktınız.Agent kurulumu yapabilmek için bildiğiniz standart agent kurulumu ;

install agent

ascagentforw

agentforw2

Agent kurulumunu tamamladıktan sonra job’ı tekrar çalıştırdığınızda artık bu hatayı almadığınızı göreceksiniz.

Faydalı olması dileğiyle.

Office 365 Domain Ekleme ve Kullanıcı Oluşturma İşlemleri

No Comments

 

Merhaba , bu makalemde Office 365 üzerinde domain ekleme ve yapılandırma işlemlerinden bahsedeceğiz .Office 365 ile birlikte artık domainlerimizi Office 365 ile yapılandırabiliyor ve mail trafiğini kesintisiz bir şekilde sağlayabiliyoruz. Microsoft’un bize verdiği sla yüzdesi %99.98 . Office 365 i neden tercih etmek gerekir diye sorarsanız arka planda tüm sunucu yönetimi Microsoft’a ait. Office 365 hizmeti SaaS olarak geçmekte yani software as a service. SaaS modelinde operasyonel maliyetler düşer ; sunucu maliyetlerleri,teknik bakım gerektiren işlerle uğraşmazsanız. Lisanslama ve güncellemeler dahil hepsi servis sağlayıcının görevidir.Office 365 burada daha çok son kullanıcıyı hedef almaktadır.Benim bir adet domain’im var ve ben bu domaini Office 365 üzerinde etkinleştirip , mail kullanımını 365 üzerinden gerçekleştireceğiz.Yapılması gereken adımlar çok da karmaşık değil.

office.Microsoft.com adresi üzerinde bir hesap oluşturacağız.

Etki alanını ekleyeceğiz.Etki alanını alan adını satın aldığımız yerde TXT doğrulaması yapacağız.Eğer nameserver ı bir hosting’e yönlendirdiyseniz bu kaydı orada açmanız gerekiyor.

Kullanıcı oluşturacağız ve lisans atamasını gerçekleştireceğiz.

office.Microsoft.com adresine girip , hesap oluşturalım.Aşağıda 3 adet paket seçeneği mevcut , siz şirket yapınıza uygun paketi seçebilirsiniz.Ürünlerin karşılaştırma tablosu Microsoft’un sitesinde mevcut.http://office.microsoft.com/en-us/pc/compare-office-365-for-business-plans-FX104339486.aspx Ben biraz daha kurumsal bir paket olan orta ölçekli işletme paketini seçiyorum.Free Trial ‘a tıklıyorum.

office 365

 

Karşımıza 1 aylık deneme sürümünü kullanabilmemiz  icin bir üyelik formu geliyor.Gerekli bilgileri dolduruyoruz.

free trial

free trial2

free trial3

Gerekli bilgileri doldurduktan sonra create my account a tıklıyorum.Yukarıda oluşturduğumuz user id Office 365 paneline girerken kullanacağımız user id ‘dir.O yüzden bu bilgileri kaybetmeyin.Kaybetmeniz durumunda yukarıda tanımlamış olduğumuz cep telefonundan parolayı resetleyebiliriz.

free trial4

Save and continue diyerek devam ediyorum.Ve karşımıza Office 365 konsolu açılıyor.

office365console

Kullanmak istediğimiz etki alanını Office 365 üzerinde yapılandıracağız.Admin Center üzerinde domains tabına geliyoruz.

domains

Add a domain diyerek kurulum adımlarını başlatıyoruz.

adddomain

addadomain2

Office 365 için kullanmak istediğimiz etki alanı adını yazıyoruz.

confirm

Bu domainin bize ait olduğunu doğrulayabilmek için Microsoft mx ve ya txt kaydının hosting üzerinde oluşturmamız gerekiyor.Genel yönergelere gelip txt kaydını seçiyorum ve bunu kopyalıyorum.Şimdi bu kaydı dış dns üzerinde ekleyeceğim.

txt

Hosting paneli üzerinde txt kaydını oluşturuyorum.Bu kayıtların güncellenmesi 1-2 saat zaman alabilir.

done verify

done , verify now diyerek doğrulama işlemini başlatıyorum.

confirmed

Txt kaydımız doğrulandı finish diyerek domain ekleme işlemini tamamlıyorum.

add users

2 adımda kullanıcı oluşturma ve lisans atama işlemlerini gerçekleştireceğiz.Start Step 2 diyerek başlatıyoruz.

addusers2

İstersek kullanıcıları tek tek oluşturabilir ve ya csv dosyasından import edebiliriz.Ve ya bu adımı atlayabilir ve sonra kullanıcılarımızı oluşturabiliriz.Ben ilk seçeneği seçiyorum.Bir kullanıcı oluşturacağım.Hybrid yapılanma için active directory ile senkronize edebiliriz.Melez yapılanma başka bir makalede detaylı olarak anlatılacaktır.

new user

Can Bolat için cbolat@canbolat-tr.com için bir hesap oluşturuyorum.

settings

Kullanıcı lokasyonunu belirliyorum.Üst seçenekte bu kullanıcının yönetici haklarına sahip olmasını ister misiniz diye soruyor.Bir tanımlama yapmayacağım.Rol tanımları detaylı olarak ilerde anlatılacaktır.

licenses

Kullanıcının hangi servislerden faydalanabilmesini istiyorsak ilgili lisansları seçiyoruz.

send results

Oluşturduğumuz kullanıcının bilgileri Office 365 te oturum açarken kullandığımız yetkili kullanıcı hesabına gönderilecektir.

results

Kullanıcımız ve geçici parola oluştu.İlk oturumda şifre değişikliği isteyecektir.Başka bir kullanıcı oluşturmayacağım finish diyerek kullanıcı oluşturma işlemini bitiriyorum.

domain purpose

3.adımda Office 365 için gerekli dns kayıtlarını oluşturacağız .Bu adımda Exchange ve Lync için dns tanımlarını yapacağız.

set domain

Exchange ve Lync Online servislerini bu domain üzerinde kullanmak istiyorsak varsayılan olarak devam edebiliriz.Yani kullanıcılar Lync ve Exchange hizmetlerini bu domainde oturum açarak kullanacaklar.

add dns records

Exchange,Lync ve Office 365 hizmetlerini kullanabilmemiz için dış dns üzerinde bu kayıtları açmamız gerekiyor.

dns management

done

Finish diyerek 3 adımımizıda tamamlıyoruz.

panel

Domain şuan da hazır ve aktif durumda.Şimdi bir test yapalım.

Office.microsoft.com adresine girip oluşturmuş olduğum kullanıcı hesabı ile oturum açıyorum.

office365

Hesabı oluştururken bize geçici bir parola vermişti.Yeni parolamızı tanımlıyoruz.

expired

Save dedikten sonra time zone seçimini  yapıp oturum açıyorum.

owa

owa1

Deneme maili gönderelim şimdi.

receive

yeap

 

Dilerim faydalı bir makale olmuştur.Sonraki makalede görüşmek üzere.

 

 

 

 

 

 

 

 

Hp Switch – Configuration

No Comments

Hp switch’ler üzerinde genellikle yapılan standart ayarlar ;

Switch’e Hostname verin.

HP Procurve 2910al(config)# hostname Switch-1
Switch-1(config)#

Password’leri set edin.

Switch-1(config)# password all
New password for operator: *******
Please retype new password for operator: *******
New password for manager: *******
Please retype new password for manager: *******
Switch-1(config)#

Time zone’u ve time server’lari (192.168.1.200 gibi) set edin.

Switch-1(config)# time timezone 120
Switch-1(config)# time daylight-time-rule Western-Europe
Switch-1(config)#
Switch-1(config)# sntp server 192.168.1.200
Switch-1(config)# sntp server priority 1 192.168.1.200
Switch-1(config)# timesync sntp
Switch-1(config)# sntp unicast
Switch-1(config)# sntp 300
Switch-1(config)#

Default Gateway IP adresini set edin.

Switch-1(config)# ip default-gateway 192.168.1.1
Switch-1(config)#

Management için belli IP adreslerine izin verin.

Switch-1(config)# ip authorized-managers 192.168.1.200 255.255.255.255
Switch-1(config)#

veya

Switch-1(config)# ip authorized-managers 192.168.1.0 255.255.255.0
Switch-1(config)#

Ayrica radius server varsa veya uygulabiliyorsa, bu server’la authentication yapilabilir.

Switch-1(config)# radius-server host 192.168.1.200 key secret_key1
Switch-1(config)# radius-server timeout 1
Switch-1(config)# radius-server retransmit 1
Switch-1(config)# aaa authentication console login radius local
Switch-1(config)# aaa authentication console enable radius local
Switch-1(config)# aaa authentication telnet login radius loca
Switch-1(config)# aaa authentication telnet enable radius local
Switch-1(config)# aaa authentication web login radius local
Switch-1(config)# aaa authentication web enable radius local
Switch-1(config)# aaa authentication ssh login radius local
Switch-1(config)# aaa authentication ssh enable radius local
Switch-1(config)# aaa authentication login privilege-mode
Switch-1(config)#

Logging ayarlarini set (logging host olarak 192.168.1.200 gibi) edin.

Switch-1(config)# logging 192.168.1.200
Switch-1(config)# logging facility local0
Switch-1(config)#

Genel SNMP ayarlarini (snmp trap’lerini 192.168.1.200 IP adresine göndermek gibi) set edin.

Switch-1(config)# snmp-server host 192.168.1.200 “public”
Switch-1(config)# snmp-server community “public” manager restricted
Switch-1(config)#

Switch’e erisimi SSH ve HTTPS ile yapilacak sekilde set edin.

Switch-1(config)# crypto key generate ssh
Switch-1(config)# ip ssh
Switch-1(config)# crypto key generate cert 1024
Switch-1(config)# web-management ssl
Switch-1(config)# no web-management plaintext
Switch-1(config)# no telnet-server
Switch-1(config)#

Switch port’larinin hizlarini ve baglanti parameterlerini set edin. Dogal olarak baglanan aygita bagimli olarak
düzgün bir setting yapilmasi lazim.

Switch-1(config)# interface 1
Switch-1(eth-1)# name “Server Connection”
Switch-1(eth-1)# speed-duplex auto-1000
Switch-1(eth-1)# exit
Switch-1(config)#

Switch’ler arasi veya server’lara birden fazla port ile baglanti durumunda Port Trunk ayarlarini set edin.

Switch-1(config)# trunk 1-4 trk1 trunk
Switch-1(config)#

veya

Switch-1(config)# trunk 1-4 trk1 lacp
Switch-1(config)#

Switch port’larinda broadcast limitini (toplam port bant genisliginin %20’si gibi)set edin.

Switch-1(config)# interface 1
Switch-1(eth-1)# broadcast-limit 20
Switch-1(eth-1)# exit
Switch-1(config)#

Switch üzerinde Spanning Tree protokolünü aktif edin.

Switch-1(config)# spanning-tree
Switch-1(config)# spanning-tree force-version rstp-operation
Switch-1(config)#

Switch port’larinda BPDU (Bridge Protocol Data Units) filtrelemesi yapin.

Bu port’lara baska bir switch’in veya Spanning Tree protokolü ile iletisimde bulunan baska bir aygitin takili
olmadigina dikkat edin. Filtreleme yapinca ilgili port’tan bridge ile ilgili paketlerin gelmesi engellenmis
olacagindan bu port’ta Spanning Tree protokolü aktif olarak çalismayacaktir.

Switch-1(config)# spanning-tree 1-23 bpdu-filter
Switch-1(config)# spanning-tree 1-23 bpdu-protection
Switch-1(config)#

Switch port’larinda loop’u engellemek için gerekli ayari yapin (24 no’lu port diger switch’e baglanti için).

Switch-1(config)# loop-protect 1-23
Switch-1(config)#

Switch üzerinde DHCP (Dynamic Host Configuration Protocol) snooping ayarini set edin. Bu ayar sizin isteginiz
disinda agda DHCP servisi çalistiran bir host’un IP dagitmasini engeller (iki DHCP server var 192.168.1.200 ve
192.168.1.201 gibi). Client’larin bagli oldugu port’lar 2-20 gibi bunlarin güvenilir oldugunu belirtmek gerekli.

Switch-1(config)# dhcp-snooping
Switch-1(config)# dhcp-snooping vlan 1
Switch-1(config)# dhcp-snooping authorized-server 192.168.1.200
Switch-1(config)# dhcp-snooping authorized-server 192.168.1.201
Switch-1(config)#
Switch-1(config)# interface 1-23
Switch-1(eth-2-20)# dhcp-snooping trust
Switch-1(eth-2-20)# exit
Switch-1(config)#

Bunun yaninda IGMP (Internet Group Management Protocol) ve MLD (Multicast Discovery Protocol) snooping
ayarlarini da yapabilirsiniz.

Switch üzerinde ARP (Address Resolution Protocol) korumasini aktif edin. Öncelikle DHCP snooping’in set edilmesi
gerekiyor. Vlan 1 için arp protect set edildi ve diger switch’e veya router’a baglanti için kullanilan port 24 no’lu
port trust edildi (bu port üzerinde arp kontrolü yapilmasin).

Switch-1(config)# arp-protect vlan 1
Switch-1(config)# arp-protect trust 24
Switch-1(config)#

Switch üzerindeki Vlan’lara IP adresi verin ve IP routing özelligini aktif edin.

Switch-1(config)# vlan 1
Switch-1(vlan-1)# ip address 192.168.1.21 255.255.255.0
Switch-1(vlan-1)# exit
Switch-1(config)#
Switch-1(config)# ip routing
Switch-1(config)#

Switch üzerinde port’lar ve kablolama ile ilgili bazi hatalari algilamak için asagidaki ayarlari set edin.

Switch-1(config)# fault-finder bad-driver sensitivity high
Switch-1(config)# fault-finder bad-transceiver sensitivity high
Switch-1(config)# fault-finder bad-cable sensitivity high
Switch-1(config)# fault-finder too-long-cable sensitivity high
Switch-1(config)# fault-finder over-bandwidth sensitivity high
Switch-1(config)# fault-finder broadcast-storm sensitivity high
Switch-1(config)# fault-finder loss-of-link sensitivity high
Switch-1(config)# fault-finder duplex-mismatch-hdx sensitivity high
Switch-1(config)# fault-finder duplex-mismatch-fdx sensitivity high
Switch-1(config)#

Exchange Server 2010 ve diğer sistemler(exchange versiyonları)için Bakım Prosedürü

No Comments

Exchange Server 2010 ve diğer sistemler (exchange versiyonları)için günlük,haftalık ve aylık bakım prosedürü

Günlük Bakım
Günlük bakım rutinleri bir Exchange Server yöneticisin en çok dikkat gerektiren işidir. Ne var ki bu görevleri gerçekleştirmek fazla zaman almamalıdır.
Online Backup Kontrolü
Felaket (disaster) ile felaketten kurtarma (disaster recovery) arasındaki en önemli farklardan biri, bir organizasyonun ihtiyaç halinde yedeklere ulaşabilmesidir. Bir Exchange ortamında yedeklerin kullanılabilir olmamasının etkileri düşünüldüğünde, yedekleme işlemlerinin sıklıkla ihmal edildiği görülür. Pek çok organizasyon , çoğunlukla teknik olmayan yönetici personelin günlük olarak ‘kartuşları değiştir’ tavrına dayalı bir ‘ayarla ve unut’ davranışı içindedir.
Exchange Server ortamının yedeği için hangi metod kullanılıyor olursa olsun, görevin başarısının günlük teyidi şarttır. Her ne kadar işlemin gerçekten doğrulanması kullanılan yedekleme çözümüne bağlı olarak değişse de, genel konsept aynıdır. Yedekleme programının log dosyasını yedeğin başarı ile alındığını görmek için kontrol edin. Eğer yedekleme görevi başarı ile tamamlanmamış ise, hatanın sebebini belirleyin ve problemi çözmek için gerekli tedbiri alın.
Bir Exchage Server ortamının yedeğini alırken akılda bulunması gereken hususlardan bazıları şunlardır:
– Bir sistem çökmesine karşı ‘System State’ verisini yedeğe dahil edin.
– Yedekleme süresinin ne kadar zaman aldığına bakın; bu süre bir hizmet düzeyi anlaşmasına (Service Level Agreement) uygun olmalıdır.
– Yedeklemenin başlangıç ve bitiş zamanlarını belirleyin; ortamı, yedekleme işleminin gecelik bakım görevi başlamadan tamamlanacak şekilde ayarlamaya çalışın.
– Yedeklemenin tamamlanmasından sonra ‘transaction log’ların başarı ile temizlendiğinden emin olun.
Boş disk alanını kontrol edin
Exchange Server 2010’un bulunduğu bütün disk bölümleri (Exchange Server sistem dosyaları, transaction loglar, ve diğerleri) yeterli boş alanın bulunduğundan emin olmak için günlük olarak kontrol edilmelidirler. Eğer bölümde boş alan kalmazsa, diske daha fazla bilgi yazılamaz, ki bu da Exchange Server’ın Exchange Server servislerini durdurmasına yol açar. Bu durum veri kaybına ve veritabanlarında hasara neden olabilir.
Her ne kadar bu işlemi elle yapman mümkün ise de, ‘önemli’ belirtiler bazen gözden kaçabilir. En iyisi, System Center Operations Manager 2007 (SCOM) veya bir diğer yazılım aracılığı ile yöneticinin disk boş alanı belirli bir eşik değer altına düştüğünde otomatik olarak uyarılmasıdır. Bu türden ürünleri kuracak kaynaklara sahip olmayan organizasyonlar için, bu işlem scriptlerle yapılabilir; boş alan belirlenmiş eşiğin altına düştüğünde bir email veya network uyarısı oluşturulabilir.


Mesaj Kuyrukları’nı (Message Queue) gözden geçirin

Message queue’lar, organizasyon içinde mail akışında zorluklar/yavaşlıklar olmadığından emin olmak için günlük olarak kontrol edilmelidirler. Bu görev için Exchange Management Console’daki Queue Viewer aracı kullanılabilir.
Queue içinde takılmış mesajlar varsa, yöneticiler nedeni bulmak için Message Tracking and Mail Flow Troubleshooter’ı kullanabilirler.
Event Viewer loglarını kontrol edin
Exchange Server 2010 serverlarda Event Viewer’daki application log’lar Warning veya Error düzeyindeki mesajlar için günlük olarak kontrol edilmelidirler. Bazı ‘Error’ mesajları doğrudan serverdaki bir probleme işaret edebilirler ise de, bazıları ortamdaki başka problemlerin belirtileri olabilirler. Her durumda en iyisi bu hataları değerlendirmek ve bu hataları en kısa zamanda gidermektir.
Bu event tiplerini filtre etmek bunlardan son 24 saat içinde oluşanları belirlemekte yardımcı olacaktır.
Alternatif olarak, eğer -System Center Operations Manager gibi- bir sistemler veya operasyonel yönetim çözümü var ise, bu işlem otomatize edilebilir, email veya network bildirimleri hata oluşur oluşmaz gönderilebilirler.
Haftalık Bakım
Günlük yönetimsel müdahale gerektirmeyen, ancak halen yoğun dikkat gerektiren görevler, haftalık bakım rutinleri olarak kategorize edilirler. Tavsiye edilen haftalık bakım rutinleri aşağıdaki bölümlerde açıklanmışlardır.
Doküman Database Dosya Boyutları
Mailbox storage sınırlaması olmayan ortamlarda mailbox database dosyaları kısa zamanda muazzam boyutlara ulaşabilirler. Database dosyaslarını bulunduran disk bölümü, belli bir kapasitenin üzerinde database büyümesini barındırabilecek büyüklükte değilse, servisler durabilir, database dosyaları bozulabilirler, performans düşebilir, veya sistem durabilir.
Mailbox dosya sınırlamaları yapılmış olsa bile, yöneticiler database dosyalarının büyüklüklerinden haberdar olmalı ve bunu dokümante etmelidirler; bu sayede büyüme oranını belirleyebilirler.
Yöneticiler, mailbox database dosyalarının büyüklüklerini haftalık olarak belgelemekle, sistem kullanımı ve ortamın kapasite ihtiyaçlarını daha iyi görebilirler.
Public Folder Replikasyonunun Kontrolü
Çoğu ortam bilgi paylaşımı için Public Folder’ları kullanır, ve Public Folder konfigürasyonları ortamdan ortama değişirler.
Farklı Exchange Server’lar arasında Public Folder datasını replike eden ortamlarda, yöneticiler bütün folderların güncel olduğundan emin olmalıdırlar.
Bir Public Folder’ın  doğru bir şekilde replike olup olmadığını belirlemek için çeşitli pratik testler mevcuttur. ‘Ex00yymmdd.log’ ve ‘Ex01yymmdd.log’ dosyalarını incelemek bu testlerden biridir. Bir problem varsa, yöneticiler problemi çözmekte bu logları kullanabilirler.
‘Online Maintenance Task’leri kontrol edin
Exchanger Server 2010 schedule edilmiş ‘Online Maintenance’ işlemleri hakkında ‘Application Log’ içine kayıt yazar. Bütün ‘Online Maintenance’ görevlerinin yerine problemsiz olarak yerine getirildiğinden emin olmak için bu Event Log’u kontrol edin.
Yöneticiler, Event Viewer’ın filtreleme kabiliyetinden faydalanarak, spesifik olayları filtre edebilirler ve bu olaylar için tarih (ve zamanı) belireyebililer. Mesela, filtreleme ile, son 1 haftada gerçekleşen bütün Event ID 1206’ları görmek çok kolaydır.
Aşağıdaki Event ID’ler düzenli bir şekilde gözlenmelidirler:
* Event ID 1206 ve 1207 – Bu ID’ler, Item Recovery’de ‘retention time’ı geçen ‘item’ların temizlenmesinin başlangıç ve bitiş zamanları hakkında bilgi verirler.
* Event ID 700 ve 701 – Bu ID’ler ‘online database defragmentation’ işleminin başlangıç ve bitiş zamanlarına işaret ederler. Yöneticiler bu işlemin Exchange Server database yedeklemeleri ile çakışmamasını ve işlemin kesintisiz tamamlanmasını temin etmelidirler.
* Event ID 9531 ve 9535 – Bu ID’ler ‘retention’ zamanı geçen silinmiş mailbox’ların temizlenmesi işleminin başlangıç ve bitiş zamanlarını gösterirler.
Kaynak Kullanımını Analiz Edin
Bir ortamı sağlıklı tutabilmek için, genel sistem ve network performansı düzenli olarak kontrol edilmelidirler. Bir Exchange Server 2010 ortamı bir istisna değildir.
En azından, yöneticiler sistem kaynaklarını en seyrek haftada bir kontrol etmelidirler. Odaklanılacak öncelikli alanlar sistem darboğazlarının dört ana nedenini içermelidirler; RAM, CPU, disk subsystem, network subsystem.
İdeal olarak, Microsoft System Center Operations Manager benzeri bir gözetleme sistemi kullanarak düzenli aralıklarla performans verisi toplamak tavsiye edilir çünkü bu data ortamdaki pozitif ve negatif trendleri ortaya çıkarır.
Offline Address Book oluşturulmasını kontrol edin
Bir Offline Address Book (OAB), kullanıcılar offline veya Cached Exchange modda çalışırlarken Global Address List’ten (GAL) directory bilgilerine offline erişim sağlamak Outlook tarafından kullanılır. Bir kullanıcı Outlook’u Cached Exchange modda ilk defa kullandığında, kullanıcının Exchange Server mailbox’ı bir lokal dosya (bir .ost dosyası) ile senkronize edilir ve Exchange Server’daki offline adres listesi kullanıcı bilgisayarındaki bazı dosyalarla (.oab dosyaları) ile senkronize edilir.
Default olarak, OAB her gün saat 05.00 itibariyle güncellenir. Değişiklikler varsai yöneticiler uzak kullanıcıların güncelleme alabilmeleri için geçerli bir OAB kopyasının varlığını görmek için Exchange Management Console üzerinde son güncelleme zamanını kontrol edebilirler. Bunun için aşağıdaki adımları takip edin:
1. Exchange Management Console’u açın.
2. Konsol ağacında Organization Configuration’u genişletin ve Mailbox’ı seçin.
3. ‘Results’ bölümünde ‘Offline Address Book’ sekmesini seçin. Görmek istediğiniz adres defterini seçin, sonra ‘Action’ bölümünden ‘Properties’i seçin.
4. ‘Modified’ alanını Offline Address Book’un son güncelleme zamanını görmek için kontrol edin.
5. Default update schedule’u değiştirmek isterseniz, bu sayfadan bunu da yapabilirsiniz. Açılır (drop-down) kutucuktan önceden belirlenmiş schedule’lerden birini seçebilirsiniz, veya ‘Customize’ı tıklayarak kendi schedule’unuzu oluşturabilirsiniz.
6. OK’e tıklayarak konfigürasyondan çıkın.
Not: OAB oluşturumakta problem yaşıyorsanız, ‘diagnostic logging’i aktive edin ve  ‘application log’daki ‘OAB generator’ kategorisindeki event’lere göz atın.
Aylık Bakım
Tavsiye edilen aylık Exchange Server 2010 bakım uygulamaları günlük veya haftalık bakım görevlerinin sıklığını gerektirmezler, ancak, ortamın genel sağlığını idame ettirmek için önemlidirler. Bazı genel aylık bakım görevleri kısaca özetlenebilirler; diğerleri aşağıdadaha fazla detayla açıklanacaklardır.
Genel görevlere aşağıdakiler dahildirler:
* ‘Online Maintenance’ rutinlerini zorla başlatmak ve ‘memory’ (RAM) kaynaklarını boşaltmak için Exchange Server2010’ları kapatıp açın. Bu işlem çoğunlukla hotfix ve/veya service pack kurulumlarına rastlar.
* Onaylanmış ve test edilmiş service pack ve update’leri kurun.
* Gereğinde, server donanımı değişikliği dahil olmak üzere, önemli server konfigürasyon değişikliklerini planlayın ve gerçekleştirin.
Exchange Best Practices Analyzer’ı Çalıştırın
Yöneticiler ortamlarındaki konfigürasyonlar ve ayarların Microsoft’un tavsiye ettiği en iyi uygulamalar ile uyum durumunu tespit için Exchange Best Practices Analyzer’ı (ExBPA) düzenli bir şekilde çalıştırmalıdırlar. Bu araç ve onun konfigurasyon dosyaları yeni ve gelişmiş ayarlarla sürekli olarak güncellenir  ve mevcut güncellemeler araç her çalıştırıldığında üzerine kurulur.
Yöneticiler
* Health check (sağlık kontrolü),
* Permission check (izin kontrolü), ve
* Connectivity test (bağlantı testi)ni düzenli aralıklarla gerçekleştirmelidirler.
Bunun için ideal zaman 3 aylık bakımlardır.
Sağlık kontrolü esnasında bir 2 saatlik performans ölçümü de yapılabilir.
Bu taramaların sonuçları kaydedilebilir ve aydan aya kıyaslanarak bazı problemlerin varlıkları belirlenebilir.
Kesintisiz Güç Kaynağı (Uninterruptible Power Supply: UPS) Testi Yapın
Kesintisiz güç kaynağı ekipmanı yaygın bir şekilde sistemleri ani güç kayıplarından korumak için kullanılır. Çoğu UPS çözümleri enerji kesintilerinin uzun sürmesi halinde bataryalar tamamen boşalmadan serverların düzgün şekilde kapatılmalarını sağlayarak sistem bütünlüğünü koruyan yönetim yazılımları içerirler. Her üreticinin test için spesifik bir tavsiyesi vardır; bu işlemler dikkatle gerçekleştirilmelidirler. Bu testler ayda birden az olmamalı iseler de, en uygunu serverların yeniden başlatılmaları zamanına denk getirmektir.
Üç Aylık Bakım
Üç aylık bakımlar sık yapılmasalar dahi bazıları hizmet kesintisine yol açabilirler; daha önemlisi, doğru planlanmaz ve gerçekleştirilmezler ise Exchange Server 2010 organizasyonunda ciddi problemlere yol açabilirler. Yöneticiler bu görevleri yerine getirirken çok dikkatlı ve özenli olmalıdırlar.
Genel üç aylık bakım görevlerine şunlar dahildirler:
* Mailbox ve Public Folder store’larının Property sayfalarını
* konfigürasyon parametrelerini kontrol,
* Kullanım istatistiklerine göz atmak, ve
* Mailbox büyüklüklerini görmek için gözden geçirin.
* Server hard disklerindeki data büyüme oranını değerlendirerek bütün disk bölümlerinde yeterli boş alan olduğundan emin olun. Bu değerlendirme, haftalık bakım görevleri esnasında elde edilen bilgilere dayalı olarak yapılır.
Information Store Backup’larının Doğrulamasını Yapın
Daha önce söylendiği üzere, bir ortamın data yedeklemesi bir organizasyonun bir felaket halinde kurtarılabilmesini sağlama yolunda atılan en önemli adımlardandır.
Ancak, yalnızca datanın yedeklenmesi, ve geri dönüş olabileceğinin kabul edilmesi yetersizdir.
Yedekler sistemlerin geri döndürülebilirliğinden emin olmak için bir test ortamında düzenli olarak test edilmelidirler. Bir test ortamında düzenli olarak yedekten geri dönüş testleri gerçekleştirmekle yöneticiler çeşitli hizmetleri vermiş olurlar:
* Datanın doğru bir şekilde yedeklendiğinin onaylanması,
* Gerçek geri dönüş prosedürlerinin doğrulanması,
* Bir Exchange Server ortamının yedekten kurtarılması için gereken adımların atılmasında yeni Exchange Server yöneticilerinin eğitimi,, veya mevcutların pratik yapmaları.
Düzenli biçimde yedekten geri dönüş işlemleri testleri uygulamayan organizasyonlar çoğunlukla gerçekten gerektiğinde donanım eksiklikleri, yazılım eksiklikleri, yetersiz veya hatalı prosedürler, prosedürlere aşina olmayan yöneticiler, en kötüsü ise sağlam olduğu kabul edilen ancak geri döndürülemeyen yedekler gibi sebepler yüzünden gereğinden çok daha uzun süren kurtarma süreçleri yaşarlar.

Faydalı olması dileğiyle.