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...
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ő.
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.
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ó).
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)