windows server 2008 r2 hyperv,de tmg kullanmak

merhabalar

evet yeterlidir.

kolay gelsin

şöle örnek versem   sımdı     sıfırdan bır sunucu kurulumu yapıldı 2 adet ınterfıce var   suan 1 kullanılıyor lan olarak dıgerı dısable durumunda.

sımdı ben  hyper v kurup  uzerıne tmg kurmak ıstıyorum ılk yapmam gerek adım ne olcak

dısable olan ınterfece enaple edıp modemden cıkan kabloyu enaple ettgım yere takmam gerekıyor sanırım pekıo modeme takılan ınterfıce herhangı bır ıp gırmeme gerek varmı ılk soru bu .

pekı hyperv kurarken her ıkı ınterfe secmem gerekıyormı yoksa kurulumda sadece lanı secıp kurduktan sonra 2 ınterfıce secıp ıp yapılandırmasını ordamı yapmam gerekıyor  tmg sunucuda cıft eternet olcak bırı lan dıgerı wan ama asıl sunucuda ıp gırmeme gerek olcakmı wan bacagına yoksa apıpa ıp alcak

Selam,

Bu ürün için Recommended config. 3 fiziksel NIC tir.

İki external network yaratacaksınız. Bu external networkleri eşleştireceğiniz fiziksel NIC'lere ip vermek zorunda değilsiniz. Bir external network Modeme yani internete bakacak. Diğer external network LAN'a bakacak. TMG VM'i üzerinde 2 virtual NIC olacak. Bir vNIC ilk external network'e, diğer vNIC ikinci external network'e bağlı olacak (yani WAN ve LAN bacakları). 3ncü fiziksel NIC ise Host manage için kullanılacak.

Yani:

serhat hocam bu örneklemede hyper v hosta  3  adet nıcmi  olması gerekıyor  verdiğiniz örenekte  Host manage için kullanılacak kastınız ne anlayamadım hocam.

şöle anlatsam daha guzel olcak hocam daha cok bılgı vererek

1 adet ıbm sunucum var ve uzerınde 2 adet nic var   ben bu sunucuya wın 2008 r2 kurdum sunucunun rolu dc rolunde.

1nıc ip 192.168.1.1 2  NİC2  suan için dısable edılmıs durumda

ilk sorum şu olsun  hocam server manegemt kısmında hyperv kurulumunu yaparken benım karsım nıc secımı gelıyor burada Ben NIC1 SECECEM yoksa NIC2 YIMI sececem hocam. yada nıc secmeyım sonradan konsoladan eklerken ınternal olarakmı yoksa external olarakmı eklıcem nıc1 ıle nıc2 yoksa bırı ınternal nıc2 ıse externalmı eklemem gerekıyor yada her ıkı nıc hyperve konsoldan eklerken externalmı yapmam gerekıyor

ben nıc1 secıp devam ettım farz edelim.

daha sonra sunucu acılıp kapanıp açıldıgında  hyper konsolunu acıp once nıc2 eklıyorum eklerken externalı secıyorum  daha sonra new dıyerek sanal sucumu oluşturuyorum

tabı bu arada dc uzerınde 4 adet nıc gozukmetedır.  ıkıncı sorum burda dc uzerındekı 1 nıc ve nıc2 uzerınde ıp tanımlaması yapmaya gerek varmı nıc1 bırde ıp vardı ama nıc2 ıp yoktu oraya modemın takacam .

daha sonra sanal tmg kurulumu bıttıkten sonra  lan bacaga 192.168.1.2 yazıyorum wan bacagını 10.0.0.2 yazıyorum

3 adet fiziksel NIC kullanmanı tavsiye ederim. Yani elindeki sunucu üzerine 1adet daha fiziksel NIC ekle.

Bunun dışında windows server 2008 r2 DC rolündeyse üzerine birde hyper-v yüklemeni tavsiye etmem. Eğer Hyper-V kullanacaksan sunucudan DC rolünü kaldır ve DC'i hyper-v üzeründe sanal olarak çalıştır (ve şansın varsa fiziksel ortamda bir adc ile yedekle)

Yapmak gerek ise şunlar.

- DC kaldırma şansın varsa kaldır.

- Hyper-V rolünü ekle ve kurulum sırasında herhangi bir NIC seçme.

- Şu noktada Fiziksel NIC'lere herhangi bir ip vermek zorunda değilsin (3 adet NIC olduğunu düşünüyoruz)

- Hyper-V kurulumundan sonra yeni bir external network yarat ve 1nci NIC ile ilişkilendir. Bu NICten çıkan ethernet kablosu modeme gitsin ve bu external network ismi eSW-Wan. Bu NIC üzerinde external network yarattığında ağ bağlantıları altına yeni bir connection eklenecek (bu aslında sanal bir NIC) ve yeni ağ bağlantısını sil.

- Sonra ikinci bir external network daha yarat ve ismini eSW-LAN yap ve 2nci fiziksel NIC ile ilişkilendir. Bu NICten çıkan ethernet kablosu ise LAN'a bakan fiziksel switche gitsin. İkinci NIC üzerinde external network yarattığında ağ bağlantıları altına yeni bir connection daha eklenecek ve bunu da sil.

- 3ncü NIC üzerinde herhangi bir network yaratma  ve bu fiziksel NIC'e ip ver. Vereceğin IP hyper-v hostuna erişmek için kullanacağın ip olmalı. DNS, gateway vs.. tanımlarını da bu NIC üzerinde yapmalısın.

- Daha sonra bir VM yarat ve üzerine iki sanal NIC ekle. ilk NIC'i eSW-WAN'a bağla ve modem ile konuşabileceği bir ip ver. Bu VM'in WAN bacağı olacak. İkinci NIC'i ise eSW-LAN'a bağla ve landan bir ip ver. Bu da LAN bacağı olacak.

- Bu noktadan sonra TMG config. yapabilirsin.

- Bir VM daha yarat ve bu da DC olsun. üzerindeki sanal NIC'i eSW-LAN'a bağla.

- ve son olarak şansın varsa DC'i fiziksel ortamda ADC ile yedekle.

Doğru yapı budur 🙂

cok guzel anlatınız hocam tsk ederım   dc kaldır demısınız dc sanala kurmak bıraz rısk deyılmı sızce dc basına bır sey geldımı yandık sanalda yanı fızıksel ortamda enazında bırazda ıyı olmazmı . pekı ben dc yaptıgımda ve dc uzerıne kurarsam bana nasıl bır sorun yaarata bıilir ve bu arada 2 sanal kurun dıyosunuz  sunucunun ozellıklerı yetermı bıze performas acısından

sunucu ozellıklerı ıbm 3650 e 5420 ıslemcı ve 4 gb rem  dıskler 146 15 rpm 3 adet dısk raid5

3 nıc olayına sole anladım   3 adet fızıksel nıc  oldugunda   2 adet fızıksel nıc vm ıcın yaratıp fızıksel kısımda olusan nıclerı sılecem  3 nıc ıcın herhangı bır sey oluşturmayıp  ıp verıp onunda lan kablosunu dırek lan swıce takıcam .

benım burda merak ettıgım neden olusan ag bağlantılarında yenı connectıon oluştugunda neden sılıyorum ve sılerken hangısını sılmem gerekıyor baglantılardan ozellıklere gırdıgımde tek bir  Microsoft Virtual Networks Switch Protocol var bu nıc aıt olanı sılcem sanırım hocam

hocam sanırım bunu dc uzerıne kursam ve 2 eternet kartı ıle yapsam aynı mantıgı uygulancak deyılımı o zmaanda nıclere ıp vermesen olcakmı

hocam yazdıklarını anladım anladım ama ımkanlar dogrultusunda malesefe anlatıgınız yapmamız suan ıcın ımkansız elımızdekı mevcut sıstem ıle yapmmamız gerekıyor

yanı :   sunucu dc olcak uzerıne hyperv kurulcan vm olarak tmg kurulumu yapılcak   ve 2 eternet kartı olcak bu sekılde bır yapıyı nasıl yapılandırayım sızce

cok guzel anlatınız hocam tsk ederım   dc kaldır demısınız dc sanala kurmak bıraz rısk deyılmı sızce dc basına bır sey geldımı yandık sanalda yanı fızıksel ortamda enazında bırazda ıyı olmazmı . pekı ben dc yaptıgımda ve dc uzerıne kurarsam bana nasıl bır sorun yaarata bıilir ve bu arada 2 sanal kurun dıyosunuz  sunucunun ozellıklerı yetermı bıze performas acısından

sunucu ozellıklerı ıbm 3650 e 5420 ıslemcı ve 4 gb rem  dıskler 146 15 rpm 3 adet dısk raid5

3 nıc olayına sole anladım   3 adet fızıksel nıc  oldugunda   2 adet fızıksel nıc vm ıcın yaratıp fızıksel kısımda olusan nıclerı sılecem  3 nıc ıcın herhangı bır sey oluşturmayıp  ıp verıp onunda lan kablosunu dırek lan swıce takıcam .

benım burda merak ettıgım neden olusan ag bağlantılarında yenı connectıon oluştugunda neden sılıyorum ve sılerken hangısını sılmem gerekıyor baglantılardan ozellıklere gırdıgımde tek bir  Microsoft Virtual Networks Switch Protocol var bu nıc aıt olanı sılcem sanırım hocam

hocam sanırım bunu dc uzerıne kursam ve 2 eternet kartı ıle yapsam aynı mantıgı uygulancak deyılımı o zmaanda nıclere ıp vermesen olcakmı

hocam yazdıklarını anladım anladım ama ımkanlar dogrultusunda malesefe anlatıgınız yapmamız suan ıcın ımkansız elımızdekı mevcut sıstem ıle yapmmamız gerekıyor

yanı :   sunucu dc olcak uzerıne hyperv kurulcan vm olarak tmg kurulumu yapılcak   ve 2 eternet kartı olcak bu sekılde bır yapıyı nasıl yapılandırayım sızce

Eğer yapıda fiziksel DC yok ise ve bu sizin kuracağınız ilk DC olacak ise ben VM'e DC kurmanızı tavsiye etmiyorum. Neden?

1.) Öncelikle ana sunucuyu zaten DC'ye join edemiyor olacaksınız 🙂 Bu da extra bir sunucudan faydalanamamak olacak.

2.) Ana sunucuyu update nedeniyle reboot ettiğinizde ne olacak? Hem AD hem de Forefront aynı anda kapanacak. Reboot sonrası Forefront açılırken DC'yi göremeyecek, çünkü DC daha geç açıldığı için muhtemelen online olamayacak ve Forefront'a login bile olamayacaksınız belki. VM'lerin açılışlarını manual yapıp, her reboot sonrası siz elle tek tek açmayı deneyebilirsiniz ama bu da zaman ve emek kaybı olacaktır. Kaldı ki gecenin bir yarısı ana makinanın mavi ekran vermesi ve ani reboot olması da bu ayar nedeniyle yapınızın uzun süre kapalı kalmasına neden olacaktır.

3.) Bence ana sunucu üzerine DC kurabilirsiniz. Hiç değilse donanımınız bu şekilde ise en mantıklı yol bu şekilde görünüyor bana.

Not: Forefront TMG'nin, Domain Controller üzerine kurulumu desteklenmiyor. Kurulum sırasında SQL kaynaklı sorunlar yaşarsınız.

Kolay gelsin.

tsk ederım

inline yapıyorum (kırmızı)

cok guzel anlatınız hocam tsk ederım   dc kaldır demısınız dc sanala kurmak bıraz rısk deyılmı sızce dc basına bır sey geldımı yandık sanalda yanı fızıksel ortamda enazında bırazda ıyı olmazmı .

Tabiki de riskli. Yukarıdaki postumu dikkatli okursan sanal çalışan DC'i fiziksel ortamda yedeklemek gerektiğinden bahsettim. 

pekı ben dc yaptıgımda ve dc uzerıne kurarsam bana nasıl bır sorun yaarata bıilir ve bu arada 2 sanal kurun dıyosunuz  sunucunun ozellıklerı yetermı bıze performas acısından

sunucu ozellıklerı ıbm 3650 e 5420 ıslemcı ve 4 gb rem  dıskler 146 15 rpm 3 adet dısk raid5

Performans konusunun ucu her zaman açıktır. Monitoring etmeden doğru yorum yapmak zor. Ancak tavsiye edilen Host için 2GB memory ayırılmasıdır. Bu durumda 2 VM çalıştırmak için küçük bir ek maliyet ile sunucuya fiziksel memory takviyesi gerekebilir.  

3 nıc olayına sole anladım   3 adet fızıksel nıc  oldugunda   2 adet fızıksel nıc vm ıcın yaratıp fızıksel kısımda olusan nıclerı sılecem  3 nıc ıcın herhangı bır sey oluşturmayıp  ıp verıp onunda lan kablosunu dırek lan swıce takıcam .

Doğru anlamışsın.

benım burda merak ettıgım neden olusan ag bağlantılarında yenı connectıon oluştugunda neden sılıyorum ve sılerken hangısını sılmem gerekıyor baglantılardan ozellıklere gırdıgımde tek bir  Microsoft Virtual Networks Switch Protocol var bu nıc aıt olanı sılcem sanırım hocam

Oluşan connection'lar sanaldır ve fiziksel NIC yerine geçer. Ancak o iki NIC üzerinde ip yada benzeri bir ihtiyacımız yok çünkü onların görevi VM'lerden gelen paketleri fiziksel networke aktarmak olacak. Parent Partition ise üçüncü fiziksel NIC'i kullanacak. Microsoft Virtual Networks Switch Protocol olanı değil diğer oluşan connection'ları sileceksin.

hocam sanırım bunu dc uzerıne kursam ve 2 eternet kartı ıle yapsam aynı mantıgı uygulancak deyılımı o zmaanda nıclere ıp vermesen olcakmı

İki NIC ile yaparsan birtanesinin yerine oluşan connection'ı silmemelisin (örneğin internal networke bakan) ve Parent Partition için ona bir ip vermelisin (olmayan 3ncü NIC gibi çalışacak). Ama tavsiye etmiyorum. Orjinal donanım maliyeti yüksek geliyor ise orta seviye bir fiziksel NIC ekleyebilirsin.

hocam yazdıklarını anladım anladım ama ımkanlar dogrultusunda malesefe anlatıgınız yapmamız suan ıcın ımkansız elımızdekı mevcut sıstem ıle yapmmamız gerekıyor

yanı :   sunucu dc olcak uzerıne hyperv kurulcan vm olarak tmg kurulumu yapılcak   ve 2 eternet kartı olcak bu sekılde bır yapıyı nasıl yapılandırayım sızce

 DC üzerine direkt hyper-v rolü ekledikten sonra virtual networkleri yarat. Biri external, diğeri internal olmalı. Daha sonra bu NIC'ler için oluşan sanal connection'lara birer ip ver (yine biri internal diğeri external ip olacak (aslında ihtiyacın yoksa external connection'ı yine silebilirsin))

but not recommended 🙂

inline 😉

Eğer yapıda fiziksel DC yok ise ve bu sizin kuracağınız ilk DC olacak ise ben VM'e DC kurmanızı tavsiye etmiyorum. Neden?

1.) Öncelikle ana sunucuyu zaten DC'ye join edemiyor olacaksınız 🙂 Bu da extra bir sunucudan faydalanamamak olacak.

Eğer yukarıda bahsettiğim gibi 3ncü fiziksel NIC'i ekleyip üzerinde virtual network yaratmadan trafiğin fiziksel switch üzerinden gelmesini sağlarsanız Host'u kendi üzerinde çalışan VM'e (DC) member yapabilirsiniz. Bu senaryo da pek tavsiye edilmiyor ama bir sorun yaratmıyor.

2.) Ana sunucuyu update nedeniyle reboot ettiğinizde ne olacak? Hem AD hem de Forefront aynı anda kapanacak. Reboot sonrası Forefront açılırken DC'yi göremeyecek, çünkü DC daha geç açıldığı için muhtemelen online olamayacak ve Forefront'a login bile olamayacaksınız belki. VM'lerin açılışlarını manual yapıp, her reboot sonrası siz elle tek tek açmayı deneyebilirsiniz ama bu da zaman ve emek kaybı olacaktır. Kaldı ki gecenin bir yarısı ana makinanın mavi ekran vermesi ve ani reboot olması da bu ayar nedeniyle yapınızın uzun süre kapalı kalmasına neden olacaktır.

Aslında çok doğru bir senaryo değil 🙂 Neden? Host shutdown edildiğinde VM'lerin alacağı aksiyonu belirleyebiliyoruz. Örneğin update nedeniyle Host restart gerekiyor. Bu durumda kapanmadan hemen önce VM'i (DC) Saved State duruma geçirebilir, Host açılırken VM'in (DC) kaldığı yerden devam etmesini sağlayabilirsiniz.

Peki bluescreen? Evet bu bir sorundur ama zaten DC'i rolü host sistemde çalıştığında da aynı risk var. Host bluescreen'e düştüğünde yine domain services offline olur.

3.) Bence ana sunucu üzerine DC kurabilirsiniz. Hiç değilse donanımınız bu şekilde ise en mantıklı yol bu şekilde görünüyor bana.

Donanım yeterliliği açısından bakıldığında belki Host üzerine domain services eklenebilir ama stabilite bakımından VM üzerinde çalışmasından pekte farkı olamayacaktır.

Not: Forefront TMG'nin, Domain Controller üzerine kurulumu desteklenmiyor. Kurulum sırasında SQL kaynaklı sorunlar yaşarsınız.

Kolay gelsin.

Eğer yukarıda bahsettiğim gibi 3ncü fiziksel NIC'i ekleyip üzerinde virtual network yaratmadan trafiğin fiziksel switch üzerinden gelmesini sağlarsanız Host'u kendi üzerinde çalışan VM'e (DC) member yapabilirsiniz. Bu senaryo da pek tavsiye edilmiyor ama bir sorun yaratmıyor.

Ana sunucuyu, içersindeki bir VM'e join ederseniz, join sonrası ana sunucu reboot isteyecektir. Reboot edeceksiniz, içindeki DC kapalı olduğu için join olamayacak. Join olayını geçtim, ilk açılışta alması gereken Policy'leri de alamayacaktır kendi üzerine. Onu da geçtim, Workgroup makinanın, member olması sonrasında Hyper-V SID'sinin değişmesi problemleriyle önceki yıllarda çok karşılaştık. SID değiştirmeden VM'i start bile edemezsiniz. 

Aslında çok doğru bir senaryo değil 🙂 Neden? Host shutdown edildiğinde VM'lerin alacağı aksiyonu belirleyebiliyoruz. Örneğin update nedeniyle Host restart gerekiyor. Bu durumda kapanmadan hemen önce VM'i (DC) Saved State duruma geçirebilir, Host açılırken VM'in (DC) kaldığı yerden devam etmesini sağlayabilirsiniz.

DC'nin saved kalması ve update sonrasında tekrar gelmesi arasında geçen süre nedeniyle ticket sistemlerinde sorun olacaktır. Yapıda tek DC olması durumunda bir sorun olmaz belki ama 2-3 DC olması halinde, Saved olarak kalan DC'nin diğer fiziksel DC'ler ile replikasyon yapması sırasında Security Compromised hatası alınması muhtemeldir. Ben Armstrong der ki: "You should never use saved state / snapshots with domain controllers - as this can be catastrophic."

Peki bluescreen? Evet bu bir sorundur ama zaten DC'i rolü host sistemde çalıştığında da aynı risk var. Host bluescreen'e düştüğünde yine domain services offline olur.

Mavi ekran halinde zaten tüm sistem down olacaktır. Reboot sonrası ana host'ta DC çalıştığı için loginde bir problem yaşamazsınız. İçindeki VM'leri de düzgün bir şekilde başlatır ve AD'den policy'leri düzgün bir şekilde çekmesini sağlarsınız. Bu senaryoda DC'nin mavi ekran vermesi bir problem yaratmayacaktır.

Donanım yeterliliği açısından bakıldığında belki Host üzerine domain services eklenebilir ama stabilite bakımından VM üzerinde çalışmasından pekte farkı olamayacaktır.

DC'ler hiç bir zaman VM üzerinde, fiziksel bir makina üzerinde çalışabildiği gibi çalışacağını düşünmüyorum, kaldı ki bu MS Virtualization blogunda da yayınlanmıştı diye hatırlıyorum. Trust kurulumları gibi durumlarda VM kaynaklı problemlere sıkça rastlanıyor. Bu yüzden root domain'in mutlaka fiziksel makinada olması tavsiye edilir. Bilmiyorum sizin iletmiş olduğunuz tavsiyeleri kim söylemiş fakat Ben Armstrong'un konuyla ilgili açıklamasına aşağıdan ulaşabilirsiniz.

http://blogs.msdn.com/virtual_pc_guy/archive/2008/11/24/the-domain-controller-dilemma.aspx

Ben Armstrong'un bu konuyu ilgilendiren açıklamaları:

Keep the root domain controller on physical hardware

Run the domain controller on top of Hyper-V anyway

Kolay gelsin.

 Yusuf bey konuyu varsayımlara değil resmi kaynaklara değinerek açıklamış. Çok teşekkür ederiz bilgileriniz için

Yusuf belliki bu postu yazmak için google da baya bir search yapmışsın 🙂 ve şuna dikkat ettim olayı başlıktaki senaryonun dışına taşımışsın.

Ana sunucuyu, içersindeki bir VM'e join ederseniz, join sonrası ana sunucu reboot isteyecektir. Reboot edeceksiniz, içindeki DC kapalı olduğu için join olamayacak. Join olayını geçtim, ilk açılışta alması gereken Policy'leri de alamayacaktır kendi üzerine. Onu da geçtim, Workgroup makinanın, member olması sonrasında Hyper-V SID'sinin değişmesi problemleriyle önceki yıllarda çok karşılaştık. SID değiştirmeden VM'i start bile edemezsiniz.

DC kapalı olduğunda ilk etapta join olamayabilir ancak kısa süre sonra authenticate olmuş olur. Kerberos ve ticket mimarisini bir incele derim. Policyler 🙂 Policyler default olarak her 90dk da bir update edilir. Bu süre senin için sorunsa GPO ile istediğin süreyi set edebilirsin. Çeşitli firmalarda 50'nin üzerinde hyper-v sunucusu yönetiyorum ve Hyper-V SID değişmesiyle ilgili bir sorundan haberim bile yok. Kaldıki defalarca workgroup çalışan ve üzerinde VM'ler olan sunucuları member yaptık ve no problem.

DC'nin saved kalması ve update sonrasında tekrar gelmesi arasında geçen süre nedeniyle ticket sistemlerinde sorun olacaktır. Yapıda tek DC olması durumunda bir sorun olmaz belki ama 2-3 DC olması halinde, Saved olarak kalan DC'nin diğer fiziksel DC'ler ile replikasyon yapması sırasında Security Compromised hatası alınması muhtemeldir. Ben Armstrong der ki: "You should never use saved state / snapshots with domain controllers - as this can be catastrophic."

Tekrar Kerberos ve ticket sistemini incelemeni öneriyorum. Ayrıca dediğim gibi konuyu farklı bir senaryoya taşımışsın. Konumuzda tek DC var ve zaten bende fizikselde yedeklenmesini önerdim.

Mavi ekran halinde zaten tüm sistem down olacaktır. Reboot sonrası ana host'ta DC çalıştığı için loginde bir problem yaşamazsınız. İçindeki VM'leri de düzgün bir şekilde başlatır ve AD'den policy'leri düzgün bir şekilde çekmesini sağlarsınız. Bu senaryoda DC'nin mavi ekran vermesi bir problem yaratmayacaktır.

Kerberos - ticket mimarisi ve GPO update süresi diyorum 🙂

DC'ler hiç bir zaman VM üzerinde, fiziksel bir makina üzerinde çalışabildiği gibi çalışacağını düşünmüyorum, kaldı ki bu MS Virtualization blogunda da yayınlanmıştı diye hatırlıyorum. Trust kurulumları gibi durumlarda VM kaynaklı problemlere sıkça rastlanıyor. Bu yüzden root domain'in mutlaka fiziksel makinada olması tavsiye edilir. Bilmiyorum sizin iletmiş olduğunuz tavsiyeleri kim söylemiş fakat Ben Armstrong'un konuyla ilgili açıklamasına aşağıdan ulaşabilirsiniz.

http://blogs.msdn.com/virtual_pc_guy/archive/2008/11/24/the-domain-controller-dilemma.aspx

Ben Armstrong'un bu konuyu ilgilendiren açıklamaları:

Keep the root domain controller on physical hardware

Run the domain controller on top of Hyper-V anyway

Yine konu bütününün dışına çıkmışsın. Senaryoda tek DC var ama sen genel konuşuyorsun.

Bu arada tavsiyeler bana ait, başkasına değil. Bunlar ürünle ilgili resmi bilgiler + kendi çalışmalarım ve testlerim sonucu oluşan best practicelerim.

Bence soruyu, yazdıklarımı ve yazdıklarını en baştan tekrar oku.

Aslında herhangi bir Google araması yapmamıştım 🙂 Ben Armstrong'un blog yazılarını elimden geldiğince takip etmeye çalışıyorum. Fakat Kerberos ve Ticket mimarisiyle ilgili önerilerinizi göz önüne alıp, araştırma yapacağım. Yanlış bildiğim şeyler var ise öğrenip düzelteyim 🙂 Bizim de yapımızda 200'ün üzerinde sanal sunucu var ve bir iki aya kadar bu sayıyı 500'e çıkartmak için çalışmalar yapıyoruz. Ben de bu yapıdan elde ettiğim deneyimlerimi paylaşmıştım 🙂 Sanırım başlığı açan arkadaş için doyurucu bir başlık oldu bu.

 İyi çalışmalar..

ben serhat hocama katılıyorum çünkü şirketime hyper v kuran yapılandıran yöneten ve zaman zaman serhat hocamdanda destek alan biriyim birkere kesinlikle hyper - v hostuna dc kurmayınız kurulmazda kurarsanız oluşturacagınız hostlar iletişim kuramaz sıkıntı çıkar dc yi sanala kur çokta saglıklı başarılı hızlı çalışıyor ben 1 yılldır kullanıyorum sorunda yok maşallah dc kesinlikle hyper-v ye kuracaksan sanala kur derim hocam güzel anlatmışın banada fikir verdin bende isayı sanallaştırmayı düşünüyordum çünkü yıgınla pc oldu bu tarz işlerden.

iyi çalışmalar.

ben serhat hocama katılıyorum çünkü şirketime hyper v kuran yapılandıran yöneten ve zaman zaman serhat hocamdanda destek alan biriyim birkere kesinlikle hyper - v hostuna dc kurmayınız kurulmazda kurarsanız oluşturacagınız hostlar iletişim kuramaz sıkıntı çıkar dc yi sanala kur çokta saglıklı başarılı hızlı çalışıyor ben 1 yılldır kullanıyorum sorunda yok maşallah dc kesinlikle hyper-v ye kuracaksan sanala kur derim hocam güzel anlatmışın banada fikir verdin bende isayı sanallaştırmayı düşünüyordum çünkü yıgınla pc oldu bu tarz işlerden.

 

 

iyi çalışmalar.

DC'yi sanala kurarken dikkat ettiğiniz noktalar ve yaptığınız
ayarlamalar hakkında bilgi verebilirmisiniz. Mesela DC için ona özel
fiziksel NIC ayırdınız mı, MAC spoofing enable durumda mı vs. Teşekkür
ederim.

sanalda çalışan dc için ayırdıgım bir nic var tabiki fakat mac adresim dynamic durumda ve hiçbir sıkıntı yaşamıyorum. başkada özel bir ayar yapmadım hyper -v versiyon 1 kullanıyourm.

sanalda çalışan dc için ayırdıgım bir nic var tabiki fakat mac adresim dynamic durumda ve hiçbir sıkıntı yaşamıyorum. başkada özel bir ayar yapmadım hyper -v versiyon 1 kullanıyourm.

Aynı fiziksel NIC 'i kullanan başka sanal makine var mı ? Teşekkür ederim.