Vmware converter & Windows OEM

Scenariul cu elementele din titlu e destul de uzual si pe scurt e cam asa: ai un server cu Windows ce trebuie convertit P2V si mutat pe un host ESX.

Doar ca dupa ce te-ai apucat de treaba iti dai seama ca licenta de Windows de pe server e OEM si te intrebi ce se va intampla dupa P2V. Rezultatul este ca Windows-ul o sa-ti ceara reactivare si chiar daca reusesti sa ii convingi pe cei de la MS sa te ajute sa-l reactivezi, tot nu e bine. Pentru ca licenta de Windows OEM e legata de hardware iar migrarea pe un alt server hardware inseamna ca ai incalcat license agreement-ul cu MS.

Testat de mine cu Windows 2003, exista o varianta prin care putem schimba Windows-ul din OEM in VLK (asta bineinteles daca avem si o licenta VLK). Dupa P2V, bootam noul server virtual de pe ISO-ul cu Windows 2003 VLK si mergem pe varianta Repair. In timpul intalarii in modul repair o sa fim intrebati de noul key si-l vom introduce pe cel de VLK. Dupa asta tot ce mai trebuie sa facem e sa reaplicam ultimele security update-uri pe server.

Banuiesc ca varianta asta se poate aplica si in cazul P2V pe Hyper-V. Dar cum nu am testat nu pot decat sa banuiesc.

PS: Am avut nevoie si de vmscsi-1.2.0.4.flp ca sa pot vedea discurile SCSI din masina virtuala.

Uraa! Avem forum Microsoft in romana!

Ups, nu merge… J
S-a rezolvat, e functional acum.

http://social.technet.microsoft.com/Forums/ro/categories

Windows 7 SP1 Install Error – 0x800F0A12

Cum zilele trecute am fost liber (de fapt am fost mai mult timp liber, asta e si motivul pentru care a fost liniste pe aici) m-am gandit sa dezgrop o problema mai veche de pe sistemul meu de acasa. Si anume SP1 de Windows 7. Recunosc ca nu l-am instalat pana acum acasa, mai mult de lene, iar cand am vrut sa o fac am primit eroarea de mai jos:

Am mai luat pauza cateva zile ca sa-mi vina cheful si am citit si ce scrie in link-ul de mai jos.

http://windows.microsoft.com/en-US/windows7/windows-7-windows-server-2008-r2-service-pack-1-sp1-installation-error-0x800F0A12

Deja eram in ceata, pana m-am gandit sa arunc un ochi pe partitiile mele de pe discul de boot:

Si atunci mi-am dat seama ca uitasem de instalarea de NxTop pe care o aveam si care facuse alta partitie activa.

Am setat din nou system reserved ca partitie activa si a mers totul perfect.

Sper sa foloseasca si altora,

Andrei.

In sfarsit, suntem respectati

Fabula:

Ieri, luni, zi lucratoare, au picat serviciile de internet de la Romtelecom. Cum era de asteptat, pe Romtelecom l-a durut in “gat” si nu a anuntat nimic. Daca le spuneai ceva, te luau cu SLA si iti calculau pana si minutele de CAND ai deschis tu sesizarea nu de cand au picat serviciile.

Duminica, zi ne-lucratoare, au picat serviciile de BPOS oferite de datacenter-ul din Irlanda. Cum nu era de asteptat, pe Microsoft chiar l-a durut undeva si a trimis un mail catre toti clientii sai deserviti de acel centru si le-a promis un discount 25% din urmatoare factura desi timpul cat au fost oprite serviciile era sub SLAul agreat in contract.

In sfarsit, vad ca suntem respectati; pacat ca doar de companiile din afara… 😐

Morala si-o face fiecare

Server Manager error 0x800F0818

Am o problema cu un server si anume primesc o eroare cand deschid Roles sau Features in Server manager. Din ce am aflat, eroarea este cauzata de lipsa unor update-uri sau fisiere lipsa ale unui update.

In mod normal, eroarea (Unexpected error refreshing Server Manager: Exception from HRESULT: 0x800F0818) se rezolva in felul urmator: http://blogs.technet.com/b/roplatforms/archive/2010/05/12/how-to-fix-server-manager-errors-after-installing-updates-hresult-0x800f0818-hresult-0x800b0100.aspx

Detalii despre cum lucreaza CheckSUR gasiti aici http://blogs.technet.com/b/joscon/archive/2010/05/26/using-checksur-and-update-packages-to-fix-corruption.aspx

Tot aici gasiti si urmatorul detaliu, care se aplica in cazul meu 🙂

“If you’re still having issues afterwards, that just means that something else is going on with the system that is going to require more than CheckSUR can accomplish. Typically, this is true corruption and it may be unrecoverable“. Ultima propozitie imi place cel mai mult 😀 Microsoft, ce pot sa zic…

De azi putem fi accesati si via www.windowsserver.ro

Ramanem in continuare Winadmin.ro, dar vom putea fi accesati si via WindowsServer.ro. Nu de alta, dar 90% din continutul nostru e specific Windows Server.

Si surpriza, domeniul WindowsServer.ro nu poate fi folosit in Office 365. Oare de ce?

Putina dezinformare de la MS.RO

Va invit sa cititi urmatorul articol, dar doar daca nu aveti altceva mai bun de facut.

http://www.money.ro/microsoft-romania-treceti-la-windows-7_1038601.html

Il invit pe domnul Galos sa citeasca Support Lifecycle pentru XP:

http://support.microsoft.com/lifecycle/?LN=en-gb&C2=1173

Si sa ne explice si noua cum imi scad costurile cu 100USD daca achizitionez Windows 7. Mai ales ca din ce observ eu articolul se adreseaza enduser-ului si nu companiilor.

PS:Windows 7 e clar superior lui XP si daca aveti bani go for it. Aici eu vreau doar sa mai scot in evidenta din perlele lui Galos.

Access-based Enumeration

Ca sa nu reinventez roata sau sa folosesc scriptul magic, o sa citez…. ABE este: Access-based enumeration displays only the files and folders that a user has permissions to access. It is a feature that was previously available as a downloadable package for the Windows Server® 2003 operating system (it was also included in Windows Server 2003 Service Pack 1). Access-based enumeration is now included in the Windows Server 2008 operating system, and you can enable it by using Share and Storage Management. (Sursa http://technet.microsoft.com/en-us/library/dd772681(WS.10).aspx)

Pe scurt, daca eu am acces la un share cu zeci de sute de subdirectoare in el dar am acces doar la unul-doua subdirectoare, ABE-ul imi arata doar acele 1-2 subdirectoare la care am acces, ascunzand celelalte subdirectoare.

Cum procedam?

1. Cream directorul Share si doua subdirectoare: Pentru User 1 si Pentru User 2. Share-uim directorul Share cu share permission la Everyone pe Full si la Security dam remove la grupul Users (vedeti ca pentru asta trebuie sa scoateti Inheritance si sa pastrati setarile).
2. Cream doi utilizatori in AD: User1 si User2.
3. Deschidem proprietatile directorului share-uit si mergem la Security. Adaugam User1 si User2 cu permisiunile implicite.
4. Deschidem fereastra Advanced Security Settings. Apasam Change Permissions si pentru User1 si User2 modificam Apply to sa fie This folder only.

   

5. In directorul Share, deschidem proprietatile subdirectorului Pentru User 1 si la Security adaugam User1 cu permisiunile default. Daca exista, stergem grupul Users. Facem acelasi lucru si pentru subdirectorul Pentru User 2, doar ca adaugam User2.
6. In acest moment, daca deschidem share-ul pe o statie din retea o sa vedem ambele subdirectoare, fiecare user avand acces doar la directorul sau. Observam ca se vede si directorul celuilalt user dar nu-l putem accesa.

   

7. Acum, ca sa ascundem subdirectorul la care userul nu are acces, trebuie sa activam ABE-ul pe acel share.

   Pe serverul unde avem creat share-ul, deschidem Share and Storage Management folosind MMC-ul.

   

8. Cu dublu click pe directorul Share o sa vedem ca Access-based Enumeration este Disabled.

   

9. Selectam Advanced si bifam Enable AEM…

   

   1. Daca accesam share-ul acum, o sa vedem doar directorul Pentru User 2 pentru ca sunt logat cu user2.
   2. 
   3. Si daca accesam cu user1…

      

Important: Nu dati acces la share-uri userilor, cum am facut eu J folositi grupuri de securitate!

MS SQL. Suspect database state.

Ieri la un client am întâlnit o bază de date MS SQL cu statut de SUSPECT…pare că după restabilire totul e ok, cel puțin până acum nu a apărut nimic critic. Deci metoda e bună și verificată:

Baza de date poate fi cu status “SUSPECT” din mai multe cauze: defecțiuni tehnice, LOG-file sau MDF-file defecte, lipsa spațiului pe disc etc. Pentru a afla cauza exactă pentru care baza de date a intrat în modul “SUSPECT”, putem să utilizăm următoarea interogare

DBCC CHECKDB (‘DatabaseName’) WITH NO_INFOMSGS, ALL_ERRORMSGS

Începem restabilirea bazei de date. Pentru simplitate vom lua cazul când este afectată baza de date utilizator.

1. Oprim MS SQL SERVER;

2. Copiem într-un loc sigur fișierele mdf și log ale bazei de date avariate;

3. Pornim serverul și ștergem baza de date avariată. La acest moment în unele cazuri, când nu este posibilă ștergerea, va trebui corectarea tabelului de sistem sysdatabases;

4. Creem o bază de date nouă, cu același nume și aceeași locație, ca și baza de date suspectă;

5. Oprim serverul și înlocuim fișierul mdf nou creat, cu cel salvat precedent;

6. Pornim serverul. În acest moment starea suspectă a bazei de date pentru noi nu mai este o problemă.

7. Executăm scriptul, care ne va permite redactarea tabelelor de sistem

Use master 
go
sp_configure ‘allow updates’, 1
reconfigure with override 
go

8. Tot acolo executăm scriptul care ne va afișa numărul status al bazei de date avariate, de exemplu, 536870912 – funcțiile full-text sunt incluse și etc

select status from sysdatabases where name = ‘<DatabaseName>’

   memorizăm această valoare în cazul eșecului restabilirii log-ului

9. Tot acolo executăm scriptul care ne va duce baza de date în emergency mode

update sysdatabases set status= 32768 where name = ‘<DatabaseName>’

10. Resetăm MS SQL SERVER;

11. Baza de date trebuie să se afle în emergency mode, și deja nu în suspect mode;

12. Executăm scriptul, care va crea un nou fișier de log la baza avariată

DBCC REBUILD_LOG(‘<DatabaseName>’, ‘<numele fișierului nou de log cu locație>’)

13. Executăm următorul script – utilizarea bazei în regim single user

Use master 
go
sp_dboption ‘<DatabaseName>’, ‘single user’, ‘true’
GO 
DBCC CHECKDB(‘<DatabaseName>’, REPAIR_ALLOW_DATA_LOSS)

  a) Dacă nu s-a reușit utilizarea bazei în regim single user mode, atunci pentru verificarea integrității datelor se poate de încercat  dbo only mode

sp_dboption ‘<databaseName>’, ‘dbo use only’, ‘true’ 

 b) Dacă totul a mers bine, atunci executăm

sp_dboption ‘<databaseName>’, ‘single user’, ‘false’ 
go 
Use master 
go 
sp_configure ‘allow updates’, 0
go

NOTA.

1. Dacă în stare SUSPECT vom găsi, de exemplu, baza de date TEMPBD, atunci va trebui să folosim recomandările  http://support.microsoft.com/kb/q288809/

2. Găsim informație interesantă și pe http://support.microsoft.com/default.aspx/kb/328354

Cu respect.

Defintii de la Microsoft

Nu intelegeam de ce ieri majoritatea calculatoarelor au gasit acest adware si l-au bagat in carantina… deh, defintiile sunt facute de Microsoft 🙂 Summary-ul de aici zice cam tot si destul de clar. Ma bucur macar ca au zis si nu au stat pititi in colt.

Summary
Adware:Win32/Hotbar displays a dynamic toolbar and targeted pop-up ads based on its monitoring of web-browsing activity. Adware:Win32/Hotbar installs a browser toolbar that works in Internet Explorer 6, 7, 8 and Firefox 3.6 and 4.0. The tool is a multi-component adware program designed to monitor user’s online browsing behavior to deliver targeted advertising. It also installs other adware components related to Win32/ClickPotato and Win32/ShopperReports. Hotbar also installs graphical skins for Internet Explorer, Outlook, and Outlook Express. It may collect user-related information and may silently download and run updates or other code from its servers.

On Jul 21, 2011 05:35 AM UTC, an update caused a temporary file related to the next Microsoft definition update to be incorrectly detected as Adware:Win32/Hotbar. At 08:51 PM UTC, Microsoft released a new signature to address the issue. Signature versions 1.109.92.0 and higher include this fix.