World of Antiohne...

Om in Windows 7 (Professional of hoger) de lokale groepen te zien dien je gebruik te maken van de Local Users and Groups manager applicatie. Deze is niet bereikbaar via één van de menu's en kan alleen gestart worden via het 'Search' scherm of door te navigeren naar de juiste map als Administrator. Open het start menu en typ in de zoekbalk lusrmgr.msc . ... of ga via de Windows verkenner naar  C:\Windows\System32\ lusrmgr .msc.

Op mijn Windows 7 laptop heb ik diverse lokale service accounts in gebruik. Deze worden allemaal getoond in het inlogmenu. Dit zijn geen accounts die ik gebruik om mee in te loggen. Om deze accounts te verbergen op het inlogscherm voer je onderstaande handelingen uit. Open de registry editor (regedit.exe). Ga naar “HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows NT\CurrentVersion\Winlogon”. Maak een nieuwe sleutel aan met de naam “SpecialAccounts”. Maak onder deze sleutel een sleutel aan met de naam “UserList”. Voeg onder de “UserList” voor ieder account dat je wil verbergen een DWORD (32-bit) Value toe met de naam van het account.

Mijn ontwikkelomgeving is een gevirtualiseerde Windows 2008 R2 server welke is ingericht als domain controller. Normaal gesproken werk ik daarop via RDP met een administrator account. Vandaag wilde ik echter inloggen met een standaard account. Dit account had ik toegevoegd aan de Remote Desktop users groep. Echter bij het inloggen kreeg ik onderstaande melding te zien. To log on to this remote computer, you must be granted the Allow log on through Terminal Services right. By default, members of the Remote Destop Users group have this right. If you are not a member of the Remote Desktop Users group or another group that has this right, or if the Remote Desktop User group does not have ths right, you must be granted this right manually. De reden hiervan is dat Microsoft de beveiliging voor domain controllers zwaarder instelt dan voor servers met een andere rol. Op gewone servers kunnen administrator en gebruikers in de groep Remote Desktop Users via RDP connecten met de betreffende ma...

Op mijn werk maken we al jaren gebruik van TFS 2005, welke we later vervangen hebben door TFS 2008, om onze sources in op te slaan. Thuis werk ik tot op heden zonder source control. Vooral de laatste tijd merk ik dat dit in sommige situaties erg vervelend is. Het wordt daarom tijd dat ik thuis ook eens mijn uitprobeersels onder source control te brengen en ik heb daarom besloten maar eens TFS 2010 te installeren op één van mijn machines. De omgeving die ik gebruik is een bestaande 64 bits Windows 2008 server met daarop SQL Server 2008 R2 en een reeds conform TFS geconfigueerde IIS 7 server. Aangezien mijn server 64 bits is start ik de installatie vanuit de x64 map van de installatie DVD. De setup detecteert dat diverse benodigde bestanden al aanwezig zijn. Na het accepteren van de voorwaarden kunnen we verder. Ik kies ervoor om naast de TFS server zelf ook de build server componenten te laten installeren. Vervolgens worden alle benodigde bestanden aangebracht op de server. De ...

In de event log van mijn Windows 2008 R2 domain controller kom ik na het starten van de server de volgende waarschuwingsmelding tegen: The WinRM service failed to create the following SPNs: WSMAN/dcname.domain.local; WSMAN/dcname. Additional Data The error received was 8344: %%8344. User Action The SPNs can be created by an administrator using setspn.exe utility. Deze melding is op twee manieren op te lossen: De suggestie van Microsoft volgen en middels de SETSPN tool zelf de service principal name zetten. Er voor zorgen dat de service principal name automatisch gezet kan worden. De WinRM service draait standaard onder het network service account en dit account heeft niet het "Validated Write to Service Principal Name" recht wat nodig is om het SPN te registreren. Oplossing twee is dus simpelweg er voor zorgen dat het account dit recht krijgt. Start "ADSIEDIT.msc" en geef een rechter muisklik op "ADSI Edit" en kies voor "Connect t...

In de Windows Event log op mijn SharePoint Server 2007 omgeving kom ik regelmatig de volgende foutmelding tegen: The application-specific permission settings do not grant Local Activation permission for the COM Server application with CLSID {61738644-F196-11D0-9953-00C04FD919C1} to the user machine_naam \sa_sharepoint SID (S-1-5-21-351182230-492081484-2363579741-1028). This security permission can be modified using the Component Services administrative tool.   Deze fout kan opgelost worden door de volgende procedure te volgen: Kopieer het CLSID naar het klembord. Open de registry editor (Start > Run > regedit) Doe een zoekactie op dit CLSID (Edit > Find...) In dit geval hoort de CLSID bij de IIS WAMREG admin Service. Open Component Services (Start > Administrative Tools > Component Services). Ga naar DCOM Config (Component Services > Computers > My Computer > DCOM Config) en zoek de IIS WAMREG admin Service regel op. Selecteer...