De obicei conectarea la un Remote Desktop Licensing Server în afara Active Directory nu are sens. Dar azi m-am trezit cu această cerință pe cap și am fost nevoit să caut procedura de activare a unui server stand-alone la care să se conecteze RD vreo cinci useri.

Am găsit soluția aici:
https://support.microsoft.com/en-us/help/2833839/guidelines-for-installing-the-remote-desktop-session-host-role-service

Într-un PowerShell cu drepturi
$obj = gwmi -namespace "Root/CIMV2/TerminalServices" Win32_TerminalServiceSetting
$obj.ChangeMode("<value>") ( 2 – pentru PerDevice, 4 – PerUser)
$obj.SetSpecifiedLicenseServerList("<licenseservername>")
$obj.GetSpecifiedLicenseServerList()

La instalarea Sharepoint 2013 Foundation SP1 pe Windows Server 2012 R2 veți întîmpina următoarea eroare: .Net Framework 4.5 prerequisites not installed. Instalatorul dă eroarea pentru că .Net 4.6+ este instalat și nu-și dă seama că asta e ce-i trebuie.

Rezolvarea: SharePoint 2013 Setup error if the .NET Framework 4.6 is installed.

Dacă nu mai e online, pe scurt, spune cam așa:

  • dezpachetați SharepointSetup (sharepoint.exe /extract:<path>)
  • înlocuiți wsssetup.dll cu wsssetup.fix (sau încercați aici).

Sau dezinstalați .net46+ (nerecomandat că e mult de muncă).

Apoi instalarea merge ca pe șine.

Security management

În lumea de azi cînd toate sunt conectate cu toate, Security trebuie să fie un rol important. De la autentificare și autorizare, pînă la asigurarea integrității datelor (a se citi coruperea intenționată a datelor) și accesibilitate. Dacă AAA (autentificare, autorizare, audit) sunt imediat recognoscibile ca Security Management, integritatea datelor nu este de obicei luată în calcul (decît pe sisteme dedicate). De obicei un sistem se asigură că datele nu sunt corupte fizic pe suportul de stocare, în timpul scrierii sau citirii, cît și de-a lungul existenței lor pe storage (eg. la un reboot forțat). În context de securitate, Integritatea Datelor identifică autorul datelor și pe cel ce le modifică. Mai mult, ne asigură că datele nu au fost modificate cu rea intenție.

O altă componentă importantă a Security este Accesibilitatea Datelor. Dacă datele sunt greu accesibile atunci ele nu vor fi folosite și business-ul își pierde interesul pentru sistem (business-ul sunt cei care plătesc și care hotărăsc folosirea unui sistem sau altul). Da, anumite date au statut special și ele vor fi accesibile conform unui sistem de securiate strict, dar de aici pînă a încurca userul în day-to-day activity pentru că esti paranoic nu e un sistem bun. Un sistem flexibil, dar fără compromisuri, este marea încercare a unui OS modern.

Audit

Auditul activității în sistem este un rol necesar pentru a determina și preveni activități nedorite în sistem. Userii normali ai unui sistem vor parcurge pașii de acțiune în ordinea lor firească, dar un răuvoitor va încerca diferite scheme de ocolire a procedurii de securitate și numai prin auditul activităților din sistem (reușite și nereușite) se va putea determina o alarmă de securiate. Aici iar dăm în capcana accesibilitații – dacă sistemul va produce o tonă de evenimente și se va isteriza pentru orice bîzîit el va fi neutilizabil și va fi folosibil doar pentru a reconstitui niște pași pe baza unor log-uri (proces necesar în cazul unor evenimente nedorite deja întîmplate, dar cum prevenția costă de zece ori mai puțin decît corecția atunci ne vom concentra mai ales pe rolul de prevenție).

Sistemul va pune la dispoziția dezvoltatorilor servicii de log și audit pentru înregistrarea evenimentelor în sistem un model unitar care să poată fi interpretat ușor. Ba mai mult, se va căuta un model integrat (sau integrabil) cu alte sisteme eterogene pentru a putea fi interpretate la nivel enterprise.

În zilele noastre cînd serviciile în cloud au luat locul aplicațiilor locale, anumiți operatori vor cere și servicii de Accounting în cadrul rolul de Audit (eg. cît timp s-a folosit un anumit serviciu, ce resurse a folosit etc.). Deși la prima vedere pare că este o parte a rolul de Audit, acesta trebuie gîndit ca un rol separat și trebuie consumat direct de aplicații și servicii. Asta pentru că exstă foarte multe scenarii pentru a gîndi servicii, de le combina resurse în pachete și de a le factura (eg. lunar la pachet sau per GB folosit sau per acces-numărdevizite etc) care depășesc definiția de Master Copntroller a unui OS.

User Interaction management

Acest rol este vital pentru dezvoltarea și longevitatea unui OS. Dacă utilizatorii nu pot intracționa eficient cu sistemul atunci ei nu vor mai intracționa deloc. Gadget-urile smart și-au luat avînt DOAR DUPĂ ce a apărut o interfață prietenoasă. Unii afirmă că acel scroll gesture a simplificat suficient lucrurile pentru user. Nu e adevărat, dar gestures au o greutate mare în adoptarea smart-X-urilor.

Deși toată lumea a fost de acord, încă de la inventarea fotografiei, că o imagine face cît o mie de cuvinte, interfața grafică de interacțiune cu un computer s-a născut destul de greu. Chiar dacă hardware-ul a permis-o relativ repede (de la începutul anilor 1970), doar pe la jumătatea deceniului opt (după lupte seculare în ani-tehnologici) interfața grafică a devenit suportată pe sisteme. Motivul invocat va fi fost costul, dar eu cred că e ceva mai adînc, psihanalizabil, legat de castă – it-iștii cu hieroglifele lor urmau avocații cu avocățeasca lor sau contabilii cu contabiliceasca lor. Greșeală fatală, azi miliardele se fac din accesibilitatea publicului larg la tehnologie.

Cerințele moderne ale UI sunt legate de user experience, multi user și remote acces. Remote acces este mai mult legată de Communication Management, dar atîrnă greu în balanță modul cum interacționezi remote cu un sistem.

Communication management

La începuturile erei noastre computerul era suficient sie însuși. Dacă mai avea și o imprimantă legată la un port intern era o unealtă și mai folositoare. Odată cu creșterea cantității de date (în lume datele se dubleză la fiecare doi ani) a existat nevoia comunicării între computere. Bumul tehnologic de astăzi se datorează proiectării inițiale corecte a acestui rol. Au creat protocoale de comunicație atît de bune încît tehnologii care nu existau în momentul proiectării au fost integrate foarte ușor, natural, în sistem. Cel mai bun exemplu sunt tehnologiile wireless care nu existau în anii 1970 cind au creat protocolul TCP/IP și care apoi au folosite împreună natural, fără eforturi de integrare.

Succesul acestui model s-a bazat pe abstractizarea diferitelor funcții necesare într-o comunicare, de la transport – mediu de comunicare, protocol, pînă la limbaj și application specific. Modelul teoretic (diferit de practica curentă) este numit Open Systems Interconection (aka OSI model). El identifică șapte nivele/layere: physical, data link, network, transport, session, presentation și application. În practică au mai apărut diverse nevoi pe care modelul standard nu le-a prevăzut, ca VLANuri, VPNuri sau transport criptat (altceva decît datele criptate), dar cum în IT practica primează acestea au fost înghesuite în OSI (cu bătăi de cap doar pentru teoreticieni).

Comunicarea între sisteme diferă esențial de comunicarea între obiecte descrisă în capitolul Object Management prin natura tipului de comunicare. În primul caz sistemele sunt procupate de legătură și transport, pentru ele datele transportate fiind necunoscute, iar în al doilea tip de interacțiune – aplicațiile cunosc serviciile pe care le consumă, dar nu le pasă cum ajung la ele. În mod ideal cele două nu se intersectează, dar în practică acestea se suprapun în nenumărarte sisteme. Cel mai bun exempl este storage-ul. Inițial, era treaba unei aplicații (de tip serviciu, dar de nivel superior) să dea acces la storage (printr-un protocol special de acces, SMB, NFS, FTP) unui sistem remote, azi storage-ul poate fi virtualizat printr-un seviciu de nivel inferior al sistemului, așa încît datele să stea în toată lumea și aplicațiile care-l folosesc să naibă habar pe unde sunt dale lor

Definiție: Sistemul de operare este o aplicație software care joacă rolul de “Master Control Program” și care face legătura între hardware și celelalte aplicații software.

Principalele atribuțiuni ale unui OS sunt:

  • hardware management – gestionarea diferitelor device-uri hardware;
  • process management – executarea diferitelor aplicații software;
  • object management – gestionarea diferitelor obiecte software (fișiere, aplicații, mașini virtuale, hardware virtualizat etc);
  • user interaction management;
  • security management;
  • communication  management;
  • instrumentation and orchestration;
  • application development;
  • audit.

Hardware management

Acesta este rolul primordial al unui OS. Chiar prin definiție rolul său este să facă legătura între hardware și celelalte aplicații software.

Deși putem imagina multe device-uri hardware pe care ar trebui să le cunoască un OS, în fapt, de-a lungul timpului obiectele hardware s-au separat în cîteva categorii bine definite, 10-12 toate. Vom găsi, în ordinea importanței hardware: procesoare, motherboards, RAMi, video, storage, networking, HIDs (human interface devices), audio. Celelalte cad în categorii foarte specializate, rămînînd pentru OS doar sarcina găsirii unor mijloace (aka porturi) de conectare la aplicații. Și porturile hardware au avut aceași evoluție și s-au standardizat, cele mai folosite azi sunt porturile seriale și porturile USB (deși USB este un port hardware și are caracter serial, nu este un port serial, fiind folosit doar pentru transport).

Cel mai mare succes în managementul hardware-ului l-a avut Windows-ul pentru că a introdus un layer de abstractizare (HAL), ceea ce a permis dezvoltarea unitară a drivere-lor hardware. (definiție: driver-ul este o aplicație software specifică unui hardware ce permite sistemului de operare accesul la funcțiile device-ului.) Astfel, aplicațiile au avut o interfață unitară pentru accesul la o întreagă clasă de device-uri fără a-i păsa ce producător a construit-o. Și invers, producătorii de hardware au avut un framework unitar pentru a-și dezvolta driverele, fapt ce i-a ajutat să creeze niște aplicații robuste (fără bug-uri).

Process management

Tot definiția ne îndrumă cătrea al doilea mare rol al unui OS. În process management sistemul încarcă în memorie o aplicație software și execută instrucțiunile sale în limbaj mașină (aka cod mașină). Procesele trebuie să fie izolate, cu acces direct doar la spațiul de memorie alocat. Accesul la resurse nu se face direct, ci prin intermediul serviciilor de sistem (sau funcțiilor de sistem, dar un serviciu, spre deosebire de o funcție, are posibilități de autentificare, de prioritizare și alte atribute moderne). Cea mai mare provocare a acestui proces este de a pune la dispoziția aplicațiilor mecanisme să-și păstreze ACIDitatea (atomice, consistente, izolate și durabile).

Caraterul ACID este dat de:

  • Atomicitate – orice operațiune fie se termină cu succes, fie se termină cu eroare nelăsînd părți modificate;
  • Consitență – orice operațiune trebuie să fie validă, ducînd aplicația dintr-o stare validă într-o altă stare validă (validă din punct de vedere al OS și nu al aplicației pentru că OSul nu poate ști ce e aia stare validă pentru ea);
  • Izolare – OSul trebuie să asigure spațiu de memorie izolat fiecărei aplicații, nepermițînd unui alt software să modifice direct în spațiul dedicat;
  • Durabilitate – odată ce o operație s-a terminat toate efectele sale rămîn, orice altă operațiune ulterioară nemaiavînd acces la datele inițiale.

Object management

Dacă primele două roluri au fost evidente și cam toate sistemele de pînă acum s-au achitat onorabil în implementarea corectă a lor, partea de Object Management a fost PROST gîndită în toate OSurile cunoscute. Daca în vremurile cu hardware scump se putea trece cu vederea lipsa de viziune asupra acestui rol primordial al OSului, azi trebuie să-l avem în centrul atenției pentru că obiectele care există și interacționează într-un OS sunt suficient de complexe și diferite așa încît comunicarea dintre ele să nea de peste cap (să introducă o complexitate nejustificată) multe aplicații propuse.

Abordarea inițială a fost everything is a file și a funcționat o vreme. Prin simplitatea ei a permis orientarea țintelor optimizării software către primele două roluri, ceea ce e de înțeles pentru că hardware-ul era scump și nu așa de rapid. UNIXul a rulat inițial pe hardware de sub 1MHz !!?! Critica principala a acestui model o aduc virușii. Nediferențierea între o aplicație și un fișier de date a făcut posibil ca aplicații malițioase să se camufleze sub formă de date (documente, poze, etc). De asemenea, dacă într-un sistem modern un obiect poate fi izolat doar la acțiuni specifice, în vechime everything is file a permis accesul tuturor aplicațiilor la tot sistemul de fișiere (fie ele de bună credință sau malware). Chiar dacă teoretic sub drepturi de acces, o simplă operațiune ce pretindea drepturi full-admin putea duce la infectarea sau accesul la date confidențiale a unei aplicații răuvoitoare latentă în sistem.

Sistemele moderne trebuie să cunoască natura obiectelor (aplicații, date chioare, hardware virtualizat, video, formulare), să le identifice, să le izoleze și să le permită doar acțiuni specifice. În ziua de azi autentificarea se face ușor prin certificate SSL, prin același mecanism de identificare existent și testat pe internet. Se practică și identificarea sursei de instalare, Apple App Store, Windows Store, GPlay obligînd dezvoltatorii să-și publice aplicațiile în cadrul unor servicii publice unice. Mecanism prin care marii producători pretind că verifică aplicațiile, fapt imposibil dat fiind numărul mare de programe și producători, dar care nu face decît să le dea un control foarte mare asupra distribuției (care azi înseamnă publicitate pe bani mulți).

Tot aici se va asigura comunicarea (standardizarea comunicării) între obiecte. S-au dezvoltat două mari protocoale DCOM și CORBA (după două mari categorii de OSuri, Win și *NIX). Practic un obiect își înregistrează serviciile publice într-un registru gestionat de sistem de unde clienții află de ele și încearcă să le consume. Celebrul Copy/Paste, indispensabil azi, este cel mai bun exemplu de comunicare asigurat de rolul Object Management și care nu era posibil în era EisF.

  • On average, each employee uses 17 cloud apps, but many organizations don’t know what is in use, or whether these apps meet security, privacy and compliance requirements
  • In 91% of organizations, employees grant their personal accounts access to the organization’s cloud storage
  • 70% of the organizations allow cloud admin activity from non-corporate, unsecured networks
  • 75% of privileged cloud accounts are not in use. These accounts might be eating up the cost of a license, or worse, increasing the attack surface of the organization
  • On average, an organization shares 13% of its files externally, of which 25% are shared publicly

Vremuri bune să te-apuci de furat secrete comerciale!

G.

Ce mai citește nea Georgică pe un blog tehnic.

iar spre surprinderea programatorilor, va include sistemul de linii de comandă Bash specific platformei Linux, disponibil până la această oră pe Windows doar prin intermediul unei mașini virtuale.

Du-te, mă, la vaci!
G.

PS.
MS face o mișcare îndrăzneață – pune o interfață grafică user friendly (nicio interfață în *nix world nu e cît de cît utilizabilă, exceptînd MacOS, dar MAC e în sine un world) peste toate uneltele Linux care s-au impus overthetime. Nu pariez pe ea, dar îi dau ceva șanse la succes. Va avea cu adevărat succes dacă aplicațiile Linux vor avea de cîștigat din acest joint (da! în ambele sensuri ale acestui cuvînt). Windows are cîteva puncte tari care lipsesc pe Linux – WMI, suport real pentru copy/paste, management console, registry (cam controversat acum, dar la vremea lor o chestie tare), UI și UX unitare. Dacă vor prinde! Dar mă îndoiesc pentru că singurul fapt certificabil pe Linux comunitar este că programatorii sunt leneși și superiori (nu-i de mine să fac o interfață intuitivă și utilizabilă, ia de-aici șapte mii de opțiuni și bate-ți capul cu ele).

These days I’m in process for selecting a framework for an application. An easy task several years ago when only Windows and Visual Studio were giving the pace. Now, on anything on web days, you have more than plenty good frameworks (and far to many shitsJS) to choose from. Here are some points you must keep eyes on:

  • YOUR APPLICATION

    I have encountered people that chosen a framework because everybody else used it and also must they. Your app will give you the most important criteria to weight a system.

  • What is framework capable of?

    Do not lay your ear on internet hearsay. There are more vaporware than facts. Test it.

  • Who support the framework

    One is Microsoft, Tweeter, Facebook and other ACME ltd who wants to get framework tested for free. Do not put your money on Google. They have made history on laying down projects (and not carrying about clients).

  • Is the framework mature? Can you see it on production?

    My experience says “use only framework versioned 3.x or about to be 3.x”. They change a lot on v1 through v2 to be stable on v3.

  • Does the framework have a comprehensive set of documentation?

    This is the most important criteria to eliminate a framework. Run away from a framework (or anything in computer area) with bad support. If the producer disconsider this part their only meaning is to get free testing.

  • your application

    I cannot emphasize enough how important is the application in the process of selecting the framework to be built on. Do not chose flexibility on flexibility only, do not chose performance on performance only, do not chose web-like on anything is on web only, do not chose scale for scale only, do not chose the popular on popularity only.

G.

  1. dezinstalați KB3035583
    run elevated WUSA /Uninstall /KB:3035583
  2. creați în regiștri urmatoarea înregistrare
    [HKEY_LOCAL_MACHINE\SOFTWARE\Policies\Microsoft\Windows\Gwx]
    “DisableGwx”=dword:00000001
  3. urmariți viitoarele update-uri și bifați hyde this update pentru KB3035583

G

A NU SE FOLOSI ÎN PRODUCȚIE! Aceste chestii pre-preparate (nu e o forțare de limbaj, acest pre-pre crează imaginea corectă asupra obiectelor în cauză) nu sunt decît invitații trimise răuvoitorilor. Dacă nu ai controlul asupra lor, de ce să mai adaugi infrastructurii tale încă un nivel de complexitate pe care să-l monitorizezi și să-l ferești de atacuri?

Doar pentru că e mai comod să iei o chestie de-a gata, s-o pui online și apoi să te lauzi cît de repede ți-ai rezolvat treaba? Atunci trebuie să-ți cauți un alt job!

Sunt ele total inutile? Nope. Pentru testare, pentru prezentarea unui concept sau pentru orice suport al unei activități intermediare (care nu este legată direct de produsul final) sunt absolut necesare – vă va ușura munca cu 80%.

G.