Automatikus mentés virtuális Windowsból szerverre

Olyan problémával kerültem szembe, aminek a megoldása a végeredményt látva nem tűnt túl bonyolultnak, mégis több órányi kutatás, tesztelés eredménye a következő megoldás.

A feladat az volt, hogy egy virtuális gépen futó alkalmazás adatbázisát minden nap automatikusan mentsem egy másik gépre/szerverre/NAS-ra. A nehézséget az okozta, hogy a hálózati meghajtók csak akkor "léteznek" a rendszerben, ha a felhasználó be van jelentkezve. Ez egy virtualizált gép esetében nem feltétlenül van így.

A megoldás 2 lépésből áll:

1. lépés: másolást végző futtatható állomány elkészítése (autobackup.bat)

net use X: \\192.168.1.2\Backup /USER:admin password
robocopy c:\Program X: /xo
net use X: /delete

Az adott IP cím minta, ide a szerver/NAS elérési címét kell megadni, ahogyan az adott könyvtár eléréséhez szükséges felhasználónévvel és jelszóval is hasonló a helyzet.
A "Robocopy" egy nagy fájlok másolására használható Windows alkalmazás. Az "/xo" kapcsoló megakadályozza a régebbi fájlok újbóli másolását/felülírását. Ez abban az esetben jöhet jól, ha a mentés alap könytára helyben is tartalmaz több mentés állományt (pl. számlázó program napi mentése esetén).

2. lépés: Ütemezés

Ehhez a Vezérlőpult > Felügyeleti eszközök > Feladatütemező szolgáltatását kell indítanunk, majd olyan ütemezést állítunk be, ahol megadjuk, hogy mely fiókkal fusson, de akkor is, ha az nincs bejelentkezve. Emellett a kívánt időzítés is megadható, így a mentések folyamatosan futnak napi/heti rendszerességgel...

 

Egy adminisztrátor megakadályozta a program futtatását probléma

A Windows 10 2017-es őszi "Creators update" frissítését követően tűnt fel. A hibát - ha mondhatjuk - az okozza, hogy a futtatni kívánt alkalmazás nem rendelkezik a Windows által is hitelesített, és/vagy érvényes aláírással, azaz a rendszer third-party (harmadik féltől származó) szofvernek tekinti. Ez legtöbb esetben a setup.exe futtatásakor jön elő.

Outlook 2003 - 2016 használatakor msg file megnyitáskor hiba

Egy partnernél több hetes átfutással sikerült megoldást találni a hibára... pedig valahol adta magát az ok.

A hiba lényege, hogy a mentett levelek *.msg néven kerülnek eltárolásra, megnyitáskor viszont hibajelzést kapunk:

"Nincs alapértelmezett levelező program beállítva, vagy az aktuális levelező program nem képes teljesíteni az üzenetkezelési kérést. Futtassa a Microsoft Oulook alkamazást és állitsa be alapértelmezett levelezőprogramként."

Persze ellenőrizve a beállításokat, az Outlook az alapértelmezett, és a *.msg fájlok megyitásához is alapértelmezettként hozzá van rendelve.

A hiba oka az, hogy a tárolt levél formátuma unicode, és mint általában a Microsoft termékei, ez sem támogatja az unicodeot, függetlenül attól, hogy az üzenet mentésénél alapértelmezésként be van jelölve.

A későbbi hiba elkerüléséhez megoldás:

Outlook 2003 és Outlook 2007:

Eszközök -> Beállítások -> Egyéb fül -> Speciális gomb -> Funkció letiltása:: Unikode formátum használata üzenetek mentésekor

Outlook 2010, Outlook 2013 és Outlook 2016:

Fájl -> Beállítások -> Levelek  -> Üzenetek mentése -> Funkció letiltása:: Unicode formátum használata

A korábban mentett üzeneteket megnyitva, mentés másként-nél ki kell választani a Fájl típusát "Outlook üzenetformátum" -ra unicode nélkül.

Távoli asztali belépés Microsoft fiókkal

Az alábbi parancs kijavíthatja, a távoli rendszerhez való csatlakozást.

  • Kattintson a jobb gombbal a Start gombra, válassza a Futtatás lehetőséget
  • Gépelje be az alábbi parancsot, de használja a Microsoft-fiók e-mail címét a példa helyett: runas /u:MicrosoftAccount\*** Az e-mail cím *** winver

Amikor a rendszer kéri, adja meg a Microsoft-fiók jelszavát. Az Enter megnyomása után elindul a "WinVer" program, amely tájékoztat arról, hogy milyen Windows-verzióval rendelkezik (bezárhatja, ezen a ponton kész).

Most már probléma nélkül csatlakozhat ehhez a rendszerhez (természetesen feltételezve, hogy a rendszer "Windows 10 Pro" verzió).

Windows 7 megosztás elérése Windows 10 alatt

A Windows 10, 2018-as őszi kiadása után a Windows 7 megosztásának elérése problémás lehet. Ennek megoldásához a következő lépések elvégzése lehet segítség:

Hálózat és tűzfal

A hálózat ikonra kattintva megjelenik a csatlakoztatott hálózat, ha kattintunk a hálózat nevére, megjelenik a Gépház hálózati panelja. Itt ismét kattintsunk az aktív hálózatra, majd állítsuk át "Magán" jellegűre.

Ha a Windows saját Deffenderét használjuk, kattintsunk duplán a "Pajzs" ikonra a tálcán, itt lépjünk a tűzfal beállításokhoz, ahol kapcsoljuk ki az aktív típus tűzfalát.

SMB 1.0 engedélyezése

A Windows Vezérlőpult -> Programok és Szolgáltatások menüpontjában a bal oldali menüben válasszuk a "Windows szolgáltatások be- és kikapcsolása" funkciót, majd a következő két paraméter bekapcsolását végezzük el:

  • SMB 1.0/CIFS File Sharing Support
  • SMB Client

Ritka esetben segíthet, azonban ajánlott a következő beállítás elvégzése:

Nem megbízható csatlakozás engedélyezése (SMB 2.0)

Futtassuk a gpedit.msc (Win+r)

Keressük meg: Számítógép konfigurációja -> Felügyeleti sablonok - > Hálózat -> Lanman-munkaállomás

Itt keressük meg a "Vendégek nwem biztonságos bejelentkezéseinek engedélyezése pontot, majd manuálisan engedélyezzük.

Ezt követően a Windows 10-ből elérhetővé válik a Windows 7 megosztás

Windows 10 Pro 2004 frissítés

Nem kis fejtörést okozott, hogy a 2004-es frissítést követően az addig müködő Ű(vagy a fenti leírással működésre bírt) csatlakozást követően a Windows 7-es gépen lévő megosztás elérhetetlenné vált (virtuális gép, amin a cég számlázása fut, frissítése körülményes, ezért a "ragaszkodás").

A hiba javítása 3 lépésben:

  • Nyitni kell egy parancssort rendszergazda joggal (futtatás CMD rendszergazdaként)
  • Registrybe beszúrni egy értéket: REG ADD HKLM\SYSTEM\CurrentControlSet\Services\LanmanWorkstation\Parameters /f /v AllowInsecureGuestAuth /t REG_SZ /d 1
  • Futtatni a Csoportjog kezelő frissítést: gpupdate (szintén parancssorban, rendszergazda joggal)