"Çözümler" bölümündeki tüm yazılar:

Local User Account yaratmak ve Gruba eklemek – Script 1

27.07.2009 | 14:39 Çözümler , Windows , Windows Server 3 Yorum

Bazı durumlarda client’lar üzerinde yeni bir local user account (yerel kullanıcı hesabı) yaratıp, bu hesabı ilgili gruba üye yapmamız gerekebilir. Domain user account yaratmak kolaydır çünkü active directory üzerinde oluşturduğumuz domain user account, eğer aksi bir ayar yok ise organizasyon içerisindeki tüm client’larda oturum açabilir. Ama söz konusu local user account ise, bu hesabın her bir client üzerinde tek tek yaratılması gerekir. Bu gibi durumlarda kolaylık olması için aşağıdaki script’i kullanabilirsiniz.

Bu script sayesinde bilgisayar üzerinde yeni bir local user account yaratılmış, bu local user account’a bir password atanmış ve account ilgili gruba member edilmiş olur. Bununla birlikte account için “password never expires” ayarıda enable olur yani password süresiz olarak geçerlidir.

Script’i buradan download edebilirsiniz.

Script içerisinde strAccount, strPswd ve son bölümdeki Set objGroup satırında grup bilgisini düzenlemeyi unutmayın.

Mstsc Tarafında Default Port’u Değiştirmek

24.07.2009 | 14:11 Çözümler , Windows , Windows Server 6 Yorum

Microsoft Terminal Services Client (mstsc.exe) yani Uzak Masaüstü Bağlantısı uygulaması bildiğiniz gibi 3389 portunu kullanıyor çünkü Remote Desktop Protocol de default olarak 3389 portunu kullanıyor.

Uzak sistem üzerinde RDP (remote desktop protocol) için dinlenen portu küçük bir registry ayarı ile değiştirmek mümkün, bunu biliyoruz.

Uzak sistem üzerinde:

HKEY_LOCAL_MACHINE\System\CurrentControlSet\Control\TerminalServer\WinStations\RDP-Tcp\

Anahtarı altında PortNumber değerini örneğin 3390 olarak düzenliyoruz. Bu listening porttur.

Bu değişikliği genelde sistemlerin güvenliğine yardımcı olmak amacıyla yaparız çünkü internet ortamına açık olan ve Uzak Masaüstü Bağlantısı ile eriştiğimiz sunucuların default port kullanması risk teşkil edebilir.

Bu durumda RDP portunu 3390 olarak değiştirdiğimiz sunucuya bağlanırken mstsc.exe’de de yazdığımız ip adresinin sonuna :3390 ekleriz çünkü bunu yazmazsak mstsc kendisi için default olan yani 3389 numaralı porttan bağlanmaya çalışır ve port numaraları eşleşmediği için sunucuya erişemeyiz.

Uzak Masaüstü Bağlantısı

:3390 gibi port bilgisini verdiğimizde ise bu bilgi client tarafında bir çok yerde görülebilir.

– mstsc adres bölümünde ki bunu yukarıda görebiliyorsunuz.

– Connecting sırasında

Uzak Masaüstü Bağlantısı Portu

– Pencere full screen değilken pencere başlığında

Uzak Masaüstü Bağlantısı Portu 3390

Gibi …

Bu bilgi client tarafında olduğu için fazla sorun teşkil etmez ama her zaman yalnız çalışamıyoruz ve bazen bu bilgiyi görmemesi gereken kişiler yanımızda olabiliyor.

Mstsc.exe için default port değiştirme şansımız var mı bilemiyorum, ayrıntılı olarak inceleme fırsatım olmadı ama size daha kullanışlı bir yöntem önereceğim.

192.168.5.250 ip adresli ve 3390 nolu portu dinleyen bir Terminal Server’a bağlanacağımızı düşünelim.

mstsc.exe çalıştırın, bağlantı bilgilerinizi girin ve save as ile kayıt edin. Dikkat edin, bağlanacağımız ip adresinin sonuna :3390 koymuyoruz.

Mstsc.exe

.rdp uzantılı bir dosya oluşacak. Bu dosyayı notepad yada uygun bir editör ile açın.

Uzak Masaüstü Bağlantısı 2

Aşağıdaki gibi bir içerik göreceksiniz.

Uzak Masaüstü Bağlantısı - Notepad

Bu bilgiler az önce kayıt ettiğimiz uzak masa üstü bağlantısına ait. Gördüğünüz gibi screen mode, width, height, wall paper, clipboard gibi çeşitli değerler yer alıyor. Bu değelerin tamamı mstsc options bölümünde yaptığımız ayarlardır.

Kırmızı ile çerçeve içine aldığım ise bağlanacağımız sunucunun IP adresi ve gördüğünüz gibi sonunda herhangi bir port bilgisi yok. Bu durumda default port olan 3389 ile bağlanılacak ama biz bunu istemiyoruz.

Biz en alt satıra port bilgisini manuel ekleyeceğiz. Aşağıdaki değeri en alt satıra ekleyelim ve dosyayı kayıt edip kapatalım.

Server port:i:3390

Uzak Masaüstü Bağlantısı - Notepad 2

Bu noktadan sonra rdp kısa yoluna tıkladığımız zaman 192.168.5.250 sunucusuna uzak masa üstü bağlantısı yapılacak ve bağlantı 3390 portu üzerinden gerçekleşecek, ama bu bilgi ne connecting sırasında ne de pencere başlıklarında asla görünmeyecek …

En güzel yanı ise farklı portları dinleyen, farklı sunucularınız için ayrı ayrı dosyalar düzenleyebilirsiniz. Eğer mstsc.exe portunu değiştirmiş olsaydık farklı rdp portu dinleyen sunuculara bağlanırken yine :port kullanmak durumunda kalacaktık çünkü yaptığımız değişiklik tüm bağlantıları etkileyecekti.

VMM: Virtual Server 2005 Host “Upgrade Available” Uyarısı

Senaryo

VMM Admin Console’a örneğin Windows Server 2003 üzerinde çalışan Virtual Server 2005 R2’yi host olarak ekledikten sonra aşağıdaki uyarıyı alabiliriz ve eklenen host üzerinde küçük bir ünlem işareti yer alır.

Virtualization service version: Upgrade Available

Upgrade Availabl

Neden

Virtual Server 2005 host’u VMM’in desteklenen tüm özellikleri ile yönetebilmek için küçük bir update işlemi gerekiyor. Hatırlarsanız aynı durum VMM ile yönetilen Hyper-V host’larda da vardı ve çözümünü burada vermiştim. Hyper-V host’lar için iki update paketi yükleyerek çözümlediğimiz bu uyarıyı, Virtual Server 2005 tarafında çok daha basit çözümleyebiliyoruz.

Çözüm

Virtual Server 2005 R2 host’a sağ tıklayıp Update Virtual Server diyoruz.

Update Virtual Server

Update tamamlandıktan sonra host üzerindeki uyarı kalkıyor.

Add Virtual Server 2005

VMM: Virtual Server 2005 Host Eklerken Error 418

Senaryo

Windows Server 2003 üzerinde çalışan Virtual Server 2005 R2 Host’u Virtual Machine Manager yönetimine eklemek istediğimizde aşağıdaki hatayı alabilirsiniz.

Error (418)
Agent installation failed om core.bemar.corp because WS-Management is not installed or it is disabled.

Recommended Action
Ensure that the Windows Remote Management service is enabled and running on the server core.bemar.corp. If necessary the WinRM component from http://go.microsoft.com/fwlink/?LinkId=84599. For more information, see the installation instructions in the VM Planning and Deployment Guide.

Error 418

Neden

Bu durum eklemek istediğimiz Virtual Server 2005 R2’nin atında çalışan Host işletim sistemi yani senaryomuzdaki Windows Server 2003 üzerinde Windows Remote Management (WS-Management) servisinin olmaması yada servisin disable durumda olmasından kaynaklanır.

Çözüm

1. Servis var ama disable durumdaysa, enable edip start etmelisiniz.

2. Eğer servis yoksa şu link üzerinden indirip install etmelisiniz: http://go.microsoft.com/fwlink/?LinkId=84599

Servis aşağıdaki gibi yerini aldıktan sonra ve host ekleme işlemini gerçekleştirebilirsiniz.

Windows Remote Management

VMM: Offline P2V Sırasında Error 2921

Senaryo

Organizasyon içerisindeki fiziksel bir sunucuyu Offline p2v yaparken aşağıdaki hatayı alabilirsiniz.

Error (2921)
VMM cannot complete the operation on the file C:\Users\SCOMSdk\AppData\Local\Temp\SCVMM.fab1d5691c\boot.wim on the HVServer.bemar.corp server. One of the following system errors occurred: a file is read-only, the specified path is a directory, or Virtual Machine Manager does not have the required permissions.

Recommended Action
Ensure that the path is valid and VMM has the appropriate rights to perform this action.

P2V Error 2921

Neden

VMM Server üzerindeki Virtual Machine Manager servisini yöneten hesabın, offline p2v yapılacak source üzerinde yeterli yetkiye sahip olmadığı durumlarda bu hatayı alabilirsiniz.

Normal şartlarda Virtual Machine Manager servisi Local System hesabı tarafından yönetilir ve bu durumda sorun yaşanmaz. Ama örneğin yapınıza OpsMgr (Oprations Manager) entegrasyonu yaptıysanız ve OpsMgr tarafındaki servisleri farklı hesaplar ile yönetilecek şekilde configure ettiyseniz (best practice yöntemidir) bu durum VMM’i de etkiler (özellikle tüm VMM rolleri ve admin console aynı server üzerindeyse) ve Virtual Machine Manager servisi farklı bir hesap ile çalışır.

Virtual Machine Manager Servisi

Çözüm

1. Servisi yöneten ilgili hesap için source üzerinde gerekli yetkileri manuel olarak verebilirsiniz (local administrators gurubuna eklemek gibi)

2. P2v conversion tamamlanana kadar servisi Local System hesabı ile çalışacak şekilde configure edebilirsiniz. P2v tamamlandıktan sonra ise tekrar eski hesabı tanımalısınız çünkü OpsMgr entegrasyonunun doğru çalışabilmesi için bu gerekli.

Hyper-V: VM üzerinde Gecikmeli Yazma Başarısız uyarısı

03.07.2009 | 23:38 Çözümler , Hyper-V 2 Yorum

Geçenlerde karşılaştığımız bir sorunla ilgili olarak makale tadında bir problem çözümü ele aldım, umarım keyifle okursunuz.

Yapıyı biraz sadeleştirerek kısaca senaryodan bahsedelim. Hyper-V Host üzerinde çalışan bir VM düşünüyoruz. Bu VM, onu tutan host sistem yani Parent Partition (Parent OS) üzerinde paylaştırılmış bir dizine erişiyor (virtual network üzerinden) ve dosya yazıyor/siliyor.

Yazıya devam etmeden önce şunu belirtmek istiyorum: bu tavsiye edilen bir yapı değildir. Parent Partition yani host sistem üzerinde bu tip hizmetler (dosya paylaşımı vs..) vermek sorunlara yol açıyor. Sağlıklı sanallaştırma yapılarında Parent Partition’lar sadece ve sadece VM’leri çalıştırmaya odaklanmalı, başka bir hizmet ile meşgul olmamalıdır. Hatta mümkünse Parent Partition’lar Windows Server Core kurulum olmalıdır. Bu nedenle senaryomuzdaki Host ve VM arasındaki dosya paylaşım işlemini production ortamlarda kullanmayın. Eğer kullanmanız gerekiyor ise, yazının sonundaki çözüm ile kullanın.

Aşağıdaki diyagram yapıyı temsil ediyor.

Hyper-V Sanal Ağ Topolojisi

Senaryodaki Hyper-V sunucusu üzerinde 2 fiziksel NIC olduğunu görebiliyorsunuz. 1nci fiziksel NIC Virtual Network için hizmet veriyor ve üzerinde Microsoft Virtual Network Switch Protocol çalışıyor. 2nci fiziksel NIC ise Virtual Network’ten ayrı olarak sadece Parent Partition’a hizmet ediyor (örneğin management işlemleri için).

Yine Parent Partititon üzerinde görünen ve 192.168.5.5 IP adresine sahip Virtual NIC ise Fiziksel NIC 1 yerine yaratılan ve Virtual Network‘e dahil olan sanal bir donanımdır. Parent Partition VM’ler ile haberleşirken çoğunlukla bu Virtual NIC’i kullanıyor.

Bu konuyu yani Hyper-V Virtual Netwrok yapısını anlamak ve fiziksel NIC’ler dururken Parent Partition üzerinde neden sanal bir NIC yer aldığını öğrenmek için daha önce ele aldığım şu konuyu incelemenizi öneririm:

Hyper-V Virtual Network Yapısı

Senaryomuzdaki VM, Parent Partition üzerindeki örneğin \\Server\Share3 isimli paylaşıma erişmek istediğinde, aşağıdaki diyagramda yeşil ile çizdiğim yolu izler.

Hyper-V Sanal Ağ Topolojisi 2

Bu normal bir davranıştır.

Anormal olan ise, VM üzerinden bu paylaşım içerisinde herhangi bir MS Office dosyası yaratıp kayıt ederken

“Gecikmeli Yazma Başarısız” / “Delayed Write Failed”

hatası alıyor olmamız ve işlemin tamamlanamaması …

Gecikmeli Yazma Başarısız

Ancak örneğin bir notepad dosyası yarattığımızda yada bir mp3 veya jpg dosyası kopyaladığımızda başarılı bir şekilde işlem tamamlanabiliyor.

Yani problemin karakteristik özelliği MS Office belgelerine özgü olması :)

Sanal makinemiz kendi host’u üzerindeki bir paylaşıma erişip MS Office belgesi yaratmak istediğinde gecikmeli yazma başarısız hatası alıyor. Problemimiz tam olarak bu.

Aslında gecikmeli yazma başarısız hatası genelde donanım (disk) kaynaklıdır ve çözümü bilinen bir sorundur: http://support.microsoft.com/kb/330174/tr . Ancak bizim senaryomuzdaki hata network üzerinde oluştuğu için makaledeki çözüm işimize yaramıyor.

Bu noktadan sonra ilk işimiz Hyper-V sunucusu üzerindeki fiziksel NIC’ler için yayınlanmış daha güncel bir driver olup olmadığını kontrol etmek oldu ancak işimize yarayacak bir driver yoktu. Yani elimizdekiler ile çözüm üretmemiz gerekiyordu :)

Garip olan ise bu hatanın bir anda ortaya çıkmış olması. Çünkü yapı uzun zamandır bu şekilde çalışıyordu ve VM’ler host üzerindeki paylaşımlara rahatlıkla MS Office belgeleri yazabiliyordu.

Bu durum ile ilgili genel event viewer kayıtlarında yada virtual network loglarında herhangi bir olay da yoktu.

Yaptığımız kontrollerde de farklı bir hata yada anormal bir duruma rastlamadık.

Bununla birlikte aynı senaryoyu farklı Hyper-V sunucular üzerinde denedik ve sorunsuz bir şekilde kendi üzerlerinde çalışan VM’lerin yine kendi üzerlerindeki paylaşımlara MS Office belgesi açıp, kayıt edebildiklerini gördük ki zaten bu işlemin doğru olarak çalışması gerektiğini biliyoruz.

Anlayacağınız ortada çok specific bir sorun vardı.

Derken host sistem üzerindeki \\Server\Share3 paylaşımına başka fiziksel sistemler üzerindeki VM’lerden MS Office belgeleri yazabildiğimizi fark ettik ve bizi çözüme götüren tespitte bu oldu :)

Sorun Parent Partition ve VM’ler arasındaki dosya paylaşımının aynı Virtual Network içerisinde gerçekleşiyor olması. Ama az önce de söylediğim gibi aslında bu sağlıklı çalışabilen bir process.

Bu durum için bilinen bir problem kaydı olmaması, bir gün öncesine kadar zaten çalışıyor olması ve farklı fiziksel sunucular üzerinde bu sorunun yaşanmaması da bu process’in doğru olarak tamamlanması gerektiği fikrimizi destekliyordu. Peki bu sunucunun sorunu neydi? (bu konuya az sonra geleceğim)

Problemi acil olarak çözmemiz gerektiği için hemen Hyper-V sunucusu üzerindeki Virtual NIC’i disable ettik çünkü Parent Partition tarafındaki dosya paylaşım trafiğini Virtual Network içerisinden çıkartmamız gerekiyordu . Böyle yaparak trafiğin 2nci fiziksel NIC üzerinden akmasını sağlamış olduk ve problemin ortadan kalktığını gördük.

Şu haliyle \\Server\Share3 paylaşımına erişmek isteyen VM’in izlediği yolu aşağıdaki diyagramda görebilirsiniz.

Hyper-V Virtual Network 1

Ve artık VM’ler host sistem üzerindeki paylaşımlara sağlıklı bir şekilde erişip, dosya yazma, okuma gibi işlemleri normal olarak yapabiliyorlardı.

Ayrıca belirtmek istiyorum; Virtual Network’leri ve Virtual NIC’leri kaldırıp yeniden yaratmamız da çözüm olmamıştı.

Peki bu soruna yol açan neydi?

Aslında elimizde kesin sonuca ulaşacak belirgin veriler olmadığı için net bir şey söylemek zor ama sıkıntının problem başlamadan bir gün önce gerçekleşen Windows Update (Parent Partition için) sonrası ortaya çıktığını söyleyebilirim. Bu düşüncemizi destekleyen ise, ortamda bire bir aynı donanıma sahip ve aynı marka 2 Hyper-V sunucusunun daha yer alıyor olması, aynı Update’leri onların da almış olması ve onlar üzerinde de aynı problemin olmasıydı. Ayrıca sunucular Windows Server 2008 logolu donanımlara sahip değillerdi. Ama yine bir gün önce Update almış ancak farklı donanım özellikleri olan, farklı marka Hyper-V sunucularda böyle bir problem yoktu.

Problem çıkartan sunucularda Asus marka server mainboard’lar ve onboard NIC’ler vardı.

Benim düşüncem ise; Windows Update sonrası fiziksel donanıma özgü (özellikle NIC tarafında) driver temelli bir sıkıntının ortaya çıktığı yönünde oldu.

Problemli sunucular production networkte hizmet ettiği için bir an önce devreye almamız gerekti ve yüklenmiş update’leri tek tek uninstall edip, problemin daha derinlerine ineme şansımız olmadı.

Sonuç olarak Virtual Network için hizmet eden fiziksel NIC’i başka işler için kullanmanın doğru olmadığını unutmayın. Eğer ki Parent Partition üzerinde farklı işler için network erişimine ihtiyacınız varsa, bunu sunucu üzerine takacağınız 2nci, 3ncü NIC’ler ile gerçekleştirin.

Örneğin senaryomuzda 1nci fiziksel NIC Virtual Network tarafına hizmet ediyor. 2nci fiziskel NIC’i ise dosya paylaşımı için kullanmış olduk. Eğer dosya paylaşımı tarafında yoğun bir trafik söz konusu ise bu NIC’i bu iş için dedicate edip, management ve diğer işlemler için 3ncü bir fiziksel NIC takabiliriz.

Gördüğünüz gibi problemin çözümü basit. Tek bir virtual NIC’i disable ederek sonuca ulaştık. Konuyu ayrıntılı ele almamın asıl amacı ise bu gibi durumlarda problemlere nasıl yaklaşmanız gerektiği konusunda fikir verebilmekti.

İyi çalışmalar.

Exchange: CCR Kurulumunda “This is not a passive node” Hatası

23.06.2009 | 14:20 Çözümler , Exchange Server 0 Yorum

Senaryo

Windows Server 2008 Cluster Node’ları üzerinde Exchange Server 2007 SP1 Cluster Continious Replication kurulumu yaparken;

İlk node üzerine ( senaryoda iki node olduğunu düşünüyoruz) Active Clustered Mailbox Role kurulumunu yaptıktan sonra ikinci node üzerine Passive Clustered Mailbox Role kurulumu sırasında aşağıdaki hatayı alabiliriz.

This is not a passive node. A clustered mailobx server represented by the cluster resource group clustername was found on this node.

CCR - Passive Clustered Mailbox Role

Neden

Aldığımız hata kurulum yapmaya çalıştığımız yani ikinci node’un Exchange CCR Passive Node olamayacağını çünkü cluster kaynaklarının zaten bu node üzerinde olduğunu söylüyor. Ama kaynakların şu an ilk node üzerinde olması gerekiyordu çünkü Exchange CCR Active Node olarak kurulumu ilk node üzerine yapmıştık yani active node ilk node olmalıydı. O halde bu hatanın nedeni nedir?

Exchange CCR Active Node (Active Clustered Mailbox Role yani ilk node) kurulumundan sonra kurulumun tamamlanması için sistemi yeniden başlatmamız gerekir ve kurulum sonunda genelde bu işlemi yaparız. Restart sırasında ilk node (active) kapandığı için doğal olarak ikinci node bu durumu farkeder ve cluster kaynaklarını kendi üzerine alır. Yani ikinci node active duruma geçer. İlk node açıldığında ise denge değişmez ve ikinci node hala active durumda kalır.

Ve biz ikinci node üzerine Exchange CCR Passive Node (Passive Clustered Mailbox Role) kurulumunu başlattığımızda cluster kaynakları hala orda olduğu için bu hatayı alırız.

Çözüm

Öncelikle ikinci node üzerinde kurulumu yarım kalan Passive Clustered Mailbox Role‘ünü uninstall ediyoruz.

Daha sonra çözüm için iki şansımız var.

1. İlk node açıldıktan sonra ikinci node‘u bir kez restart ederiz ve böylece ilk node’un tekrar kaynakları üstlenip active duruma geçmesini sağlarız.

2. Yada Failover Cluster Management konsolu üzerinde kaynakları manuel olarak diğer node üzerine taşırız.

Failover Cluster Management

Kaynakların diğer node üzerine geçtiğinden emin olduktan sonra Passive Clustered Mailbox Role kurulumunu başarılı bir şekilde yapabiliriz.

Hyper-V: VM Import Sırasında 0x80070057 Hatası

23.06.2009 | 01:12 Çözümler , Hyper-V 1 Yorum

Senaryo

A Hyper-V sunucusu üzerindeki VM’ i B Hyper-V sunucusu üzerine taşımak için kullanabileceğimiz en basit yöntemlerden birisi export/import işlemidir.

Bir VM ‘i Hyper-V Manager konsolu ile export ettikten sonra diğer Hyper-V sunucusu üzerinde yine Hyper-V Manager konsolunu kullanarak improt etmek istediğimizde aşağıdaki hatayı alabiliriz.

A Server error occurred while attempting to import the virtual machine.

Failed to import the virtual machine from import directory <Directory Path>. Error: One or more arguments are invalid (0x80070057).

A Server error occurred while attempting to import the virtual machine

Hyper-V Manager konsolu ile Export edilen aynı VM ‘i Virtual Machine Manager ile Import etmeyi denediğimizde ise aşağıdaki hatayı alabiliriz.

Error (12700) VMM cannot complete the Hyper-V operation on the <server FQDN> server because of the error:

Failed to import the virtual machine from import directory <Directory Path>. Error: One or more arguments are invalid (0x80070057) (Unknown error (0x8005))

Neden

Bu durum genelde System Center Virtual Machine Manager ile yönetilen Hyper-V sunucuları üzerindeki VM’leri export/import ederken yaşanıyor çünkü VMM tüm VM ‘lere ScopeOfResidence değeri basıyor. Bu değer o sunucu için unique bir GUID ile temsil ediliyor ve VM ‘lerin hangi havuzda olduğu bilgisini tutuyor.

Ör:

<PROPERTY NAME=”ScopeOfResidence” TYPE=”string”>
<VALUE>
413aed57-bedd-465c-8fe4-54f2ad7ae969   ** GUID değeri **
</VALUE>
</PROPERTY>

Problemin kaynağı ise Import işlemini gerçekleştirmek istediğimiz Hyper-V sunucusu üzerinde bu Scope’un olmaması. Ama bu VM ‘i export ettiğimiz aynı sunucuya Import edebiliriz çünkü Scope zaten o sunucuda.

Çözüm

Çözüm basit.

Export ettiğimiz VM’i diğer Hyper-V sunucusuna import etmeden önce, sunucuya taşıdığımız VM dosyaları arasındaki Virtual Machines dizini altında .exp uzantılı dosyayı herhangi bir editor ile açıyoruz (ör: notepad) ve ScopeOfResidence değerini siliyoruz. Yani <VALUE>…</VALUE> arasındaki GUID.

ScopeOfResidence

Yukarıda mavi olarak işaretlediğim GUID değeri her sistemde farklıdır. <VALUE></VALUE> tag’lerini silmeden sadece ortadaki GUID’i siliyoruz ve dosyayı save edip kapatıyoruz.

Daha sonra VM’i başarılı bir şekilde import edebiliriz.

MS Outlook: Gelen Mailde Dosya Uzantısı Yasaklamak

Mail ile gelen bazı dosya uzantılarının kullanıcılar tarafından açılmasını istemeyebilirsiniz.

Eğer Exchange Server, ISA Server, ForeFront vb. gibi kurumsal çözümler kullanıyorsanız işiniz kolay. Ancak her ortamda bu ürünler bulunmayabiliyor. Eğer yapınızda bu ürünler yoksa üzülmeyin. Windows üzerinde yapacağınız küçük bir Registry düzenlemesi ile Microsoft Outlook ile sunucudan çekilen maillerde bu denetimi sağlayabilirsiniz.

Dikkat etmeniz gereken nokta şu: bu denetim kullanıcının gönderdiği maillerde değil aldığı maillerde etkilidir. Örneğin kullanıcı sürekli .exe uzantılı eklere sahip mailler alıyor ama siz kullanıcının bu uzantıya sahip dosyaları almasını istemiyorsunuz. Bu noktada çözüm aşağıda

Outlook 2003 ve 2007 için geçerlidir.

Regedit açıyoruz.

HKEY_CURRENT_USER\Software\Microsoft\Office\10.0\Outlook\Security anahtarına gidiyoruz.

Yeni bir String Value yaratıyoruz ve ismini Level1Add yapıyoruz.

Level1Add değerini düzenle diyerek değer verisi olarak .zip; .jpg; .docx gibi yasaklamak istediğimiz uzantıları (arasında ; ile) yazıyoruz.

Level1Add

ve artık kullanıcımız bu uzantıya sahip mail eklerini açamıyor.

Outlook güvensiz olabilecek eklere olan erişimi engelledi

Şunu da ayrıca hatırlatmak isterim: Kullanıcılarımızın oturum açtığı hesaplar Registry ‘e müdahale edebilecek yetkideyse (ör: local admin), bu ayarı aynı şekilde devre dışı bırakma şansları vardır.

Hyper-V: Kablosuz Ağ Bağlantısı

28.05.2009 | 17:24 Çözümler , Hyper-V 1 Yorum

Eğer Hyper-V sunucularınız üzerinde Kablosuz Ağ Bağlantısı için kullanabileceğiniz ağ kartları (Wireless NIC) varsa ya da örneğin notebook üzerinde demo/test amaçlı Hyper-V çalıştırıyorsanız, aşağıdaki durumla mutlaka karşılaşmışsınızdır.

Virtual Network Manager bölümünde yeni bir External Virtual Network (eVS) yaratmak istediğinizde kablosuz ağ adaptörlerini göremezsiniz.

Normal şartlarda kablosuz ağ kartlarımızı sanal makinelerin external network iletişimi için kullanamıyoruz. Bu tasarımsal bir durumdur.

Eğer ki kablosuz ağ kartlarını sanal makinelerin external iletişimi için kullanmak istersek şunu yapabiliriz.

Önce Yeni bir Internal Virtual Network yaratın

Internal Virtual Network

Parent OS üzerinde Network Connections açın ve kablosuz bağlantı ile az önce yaratmış olduğumuz internal bağlantıyı seçerek bridge yapın.

Bridge Connection

Bridge işleminden sonra aşağıdaki gibi görünüyor olmalı.

Wriless Bridge - Kablosuz Bridge

Daha sonra sanal makinelerimizi Internal Virtual Switch ‘e (New Internal) bağlayarak kablosuz ağ kartı üzerinden External Network ‘e erişmelerini sağlayabiliriz.