Hyper-V VM-ek vCPU

Bár utána lehet nézni a neten, egyik kolléga tőlem kérdezte meg, hogy „Egy Hoston lévő fizikai processzor magok számánál, lehet-e több magot kiosztani a vm-ek közt?”

Nos, a válasz* nem egyszerű igen vagy nem, hanem attól függ (s itt jöhetne egy kétopciós válasz (2016 előtt és után), de kicsit menjünk részleteibe).

Kezdjük a szerver oprendszerű gazdagépekkel. Ha Windows 2008/R2 fut a host-on, akkor a Microsoft által támogatott vCPU-k száma 4 (azért ez a megfogalmazás, mert technikailag megoldható ennek a határnak az átlépése, de az már nem lesz támogatott).

Ha 2012/R2 a gazdagép, akkor már képbe jön a vendég-gép oprendszere is (szerencsére a 2012 R2 esetén megjelenő Gen2 még nem), ideális esetben számolhatunk 64-el – de max a logikai processzorok száma (Logical processors = Sockets * Cores * HyperThreading).

Ha 2016 vagy 2019-ről beszélünk, akkor még bonyolultabb a válasz, ugyanis képbe jön a VM generációja, illetve a vendég OS fajtája: korszerű OS esetén (2016, 2019) G1 VM-nél 64 vCPU, G2 VM-nél 240 vCPU-ig tornászható fel a szám (még ha fizikailag nincs is annyi, de ez – a méretezés – már egy másik téma). Amennyiben 2012 R2, 2012 vagy 2008 R2-nk van, akkor egységesen 64 vCPU a limit, „sima” 2008 esetén pedig max 8.

Amennyiben Windows 10-es host-ról van szó, akkor kicsit változhatnak a számok.

* Ismerve a kollégát, értettem a kérdését is – ugyanis lehet méretezésre is gondolni, de ő most konkrétan nem azt akarta kérdezni 🙂

Exchange 2019 morgás

Ugye a napokban lett véglegesítve az Exchange 2019. Eddig még lehetett reménykedni, hogy az előzetes információkkal ellentétben még van esélyünk a cikket kiváltó morgás megszűnésére, de a remény elhalt… Ugyanis szép és jó a fejlesztés, de egy dolgot emelnék csak ki belőle: a Mailbox kiszolgáló minimálisan ajánlott 128 GB memóriáját. Az MS-nél vagy nagyon elgurult a gyógyszer, vagy ezzel akarják a kkv-kat az Office365 irányába terelni.

Egyik érintett kis cég, ahol a napokban beszéltünk fejlesztésről, kapásból kilőtte ezt a verziót. Mivel vidék, rossz internet-eléréssel, ráadásul nagyon (értsd: nagyon) kis költségvetésű cég, az O365 is kilőve – így maradtunk az Exchange 2016 bevezetésénél.

Aki ismer, tudja, hogy amennyire lehet, MS-párti vagyok, ugyanakkor szakmai szempontból is meg szoktam mondani a véleményem – ennek kapcsán ez a lépés több fekete ponttal felérő minősítést ér… Csak ismétlésként, az eddigi minimális követelmények:

– Exchange 2019: 128 GB

– Exchange 2013, 2016: 8 GB

– Exchange 2010: 4 GB

 

ManagedBy attribútum

Egyik kolléga azt a kérdést szegezte nekem, hogy egy számítógép AD-fiók ManagedBy attribútuma felhasználható-e arra, hogy egy felhasználót az adott géphez kötni, pl. leltár esetén egy leltári számmal elnevezett gép tulajdonosa visszakereshető legyen.

Ez nem egy gyakran használt tulajdonság, így a pozitív válasz mellé elküldtem neki a részleteket is, viszont úgy gondoltam, érdemes ide is archiválnom.

Csoportok esetén ez a tulajdonság szinte értelemszerű, hiszen amennyiben beállítjuk az attribútum értékét és bekapcsoljuk a pipát, úgy a háttérben az adott csoport Security fülén megjelenik a „manager” és írás-jogot kap a csoporttagság módosítására.

Egy másik felhasználása az RODC-k esetén jön képbe, ugyanis ezzel tudjuk rajtuk a helyi adminisztratív fiókokat szabályozni (pl. „RODC-admins” nevű csoport), valamint a RepairAdmin értéke is ez lesz.

 

Unicode XML

Nemrég abban kérték a segítségem, hogy egy PowerShell script segítségével készített xml állomány kódolását miként lehet megváltoztatni, ugyanis azt eredetileg UTF8-ban mentették le, nekik ez viszont nem felelt meg.

Amennyiben (mint jelen esetben) egy már létező adattal dolgozunk, az alábbi példában a $XML változóban hivatkozok rá, ha viszont még nincs, akkor pl. az alábbi utasítással hozhatjuk létre:

$XML = New-Object System.Xml.XmlDocument

A kódolás változtatására a neten keresgélve több módszert is találhatunk. Ezekből próbáltam egyet megfelelően összeállítani, amely még ha nem is működik minden esetben, de az adott cél elérésében segített (az adott sorba mindenki másolja a neki megfelelő kódolást). Amit viszont “csak” dokumentáltam, hogy a különböző Unicode kódolások eléréséhez milyen paramétereket kell megadni – ez azért fontos, mert van olyan kódolás, ahova 1, van, ahol 2 paramétert kell kötelező módon megadni (minden esetben a BOM az utolsó paraméter):

# Encoding types, just for listing

# UTF8

$UTF8WithoutBom = New-Object System.Text.UTF8Encoding($false)

$UTF8WithBom = New-Object System.Text.UTF8Encoding($true)

# UTF16

$UnicodeLEWithoutBOM = New-Object System.Text.UnicodeEncoding($false,$false)

$UnicodeLEWithBOM = New-Object System.Text.UnicodeEncoding($false,$true)

$UnicodeBEWithoutBOM = New-Object System.Text.UnicodeEncoding($true,$false)

$UnicodeBEWithBOM = New-Object System.Text.UnicodeEncoding($true,$true)

# UTF32

$UTF32LEWithoutBOM = New-Object System.Text.UTF32Encoding($false,$false)

$UTF32LEWithBOM = New-Object System.Text.UTF32Encoding($false,$true)

$UTF32BEWithoutBOM = New-Object System.Text.UTF32Encoding($true,$false)

$UTF32BEWithBOM = New-Object System.Text.UTF32Encoding($true,$true)

# End listing

 

$FileName = “$Path\$name.xml”

$File = New-Object System.IO.StreamWriter($FileName, $false, $UnicodeLEWithoutBOM)

$XML.Save($File)

$File.Close()

Ez a része kipipálva 😊

Outlook form kiszórása

Az előző után ismét egy Outlook-os történet. Adva van egy custom form, .fdm formátumban, amit központilag szeretnénk kiszórni. Nos, ehhez ez a formátum nem jó, át kell alakítani .oft formába. Ehhez manuálisan betöltjük az .fdm-et, engedélyezzük a Developer menüpontot, majd ezen belül a Form szerkesztésével megnyitva, Fájl, mentés másként, elmentjük.

S itt jön a csavar. Az Office 2013-ban van egy bug, ami miatt az elmentett form nem teljesen használható, ezért az Office 2010 segítségét vettük igénybe (bizonyos okok miatt 2016 nem jöhetett szóba). Ugyanazt a műveletsort elvégezve, az elkészült form már használható volt mindkét érintett verzióban, jöhetett a tömeges telepítés.

Törölhetetlen állomány

Adott helyen abban kérték a segítségem, hogy egy adott állományt szerettek volna törölni. Természetesen, ha a szokásos módszer működött volna, nem született volna meg e cikk 😊

Ellenőrizve az alapokat, a jogosultság rendben volt, de valóban, emelt szinten sem lehetett törölni:

Parancssorból történő törlési kísérletnél:

The system cannot find the file specified.

A megoldáshoz maradjunk a régi, jól ismert DOS-os parancsnál, egy kicsit megspékelve (nem, nincs elírva, 1 idézőjel kell, s az útvonalban lehetnek szóközök is, illetve csatolt meghajtóra is működik):

del /F “\\?\Z:\mappa1\mappa 2 szokozzel akar\allomany neve

A konkrét esetben valahogy úgy sikerült létrehozniuk egy állományt, hogy az állomány neve ponttal végződött (kiterjesztés nélkül), ezért természetesen ezt is ki kellett írni a parancs sikeres végrehajtásához.

MAPI “unspecified error”

Adott helyen egy Outlook-os problémában a segítségem. Előzményként annyit érdemes tudni, hogy elkezdték bevezetni a Windows 10-et, a jelenlegi Windows 8.1 leváltására, míg Office tekintetében egyelőre még 2013 került a gépekre (jelen esetben fontos, hogy nem in-place upgrade történt).

Azokon a gépeken, ahol Win10 futott, bár ugyanúgy alapértelmezett levelező-klienssé volt téve az Outlook, ettől függetlenül egy bármilyen Office termék (Word, Excel, …) esetén, amennyiben Fájl/Megosztás/E-mail bármelyik almenüpontjára klikkeltek, egy hibaüzenetet kaptak, s nem tudták elküldeni a levelet:

Az eseménynaplót megnézve, szintén nem volt bővebb információ:

Időnként, hogy ne legyen egyszerű a történet, néha még az alábbi hibaüzenet is felpattant:

Ez utóbbi alapján próbáltak elindulni. Nos, a kapott képernyőmentések viszont azt állították, hogy mégiscsak jól van minden beállítva:

Sajnos az eredeti hibaüzenet (a MAPI-s) elég semmitmondó, a második (alapértelmezett kliens) pedig érthetetlennek tűnt. Körbejárva a problémát, kiderült, hogy bár látszólag valóban mindenhol az Outlook az alapértelmezett (pontosabban fájltípus és protokoll tekintetében az is, pl. egy mailto: rendben működött), a háttérben a grafikus felület egy registry-bejegyzést nem állít át. Ez Win8.1-en nem okoz gondot, mert az nem veszi figyelembe, Win10 esetén viszont fontos, hogy a

HKLM\Software\Clients\Mail kulcsnak a Default értéke Microsoft Outlook legyen (még üres sem felel meg neki).

Szerencsére mindezt házirend segítségével is ki lehet szórni, tehát egy több gépes környezetben is megoldódik a probléma – bár ezt csak egyszer kell átállítani, tehát ha minden gépen lefutott, a házirend törölhető is 😊