ASK

If you rename your DC by renaming a Domain Controller in the normal way you would rename a computer (using the System > Rename this PC gui), you didn’t do it right and your metadata is likely irreversibly damaged. However, I have seen success in this situation when multiple DC’s exist by demoting a re-promoting the DC. If only a single DC exists I would say its maybe a good idea to follow the below guide as it may get your out of the proverbial but probably not recommended and you may have to rely on backups.  Use the below method carefully to rename your DC in a right way and for a smooth migration Step 1: Getting ready. Open a command prompt. (Windows key+r (run) + cmd) Step 2: Adding an alternate computer name. SYNTAX : netdom computername <currentDC FQDN> / add:<newDCName FQDN> In the command prompt, type (minus quotes) “netdom computername wrongname.domain.local /add:server.domain.local“   This should return with “Added (NAME) as an alternate nam

  To achieve the objective I’m using the Invoke-Command PowerShell cmdlet which allows us to run PowerShell commands to local or remote computers. In the example below, I’ll add my User ABC to the local Administrators group on two Server (serv1, serv2) Invoke-Command -ComputerName Serv1, Serv2 -ScriptBlock {add-LocalGroupMember -Group "Remote Desktop Users" -Member ABC }   There is another everyone's favorite way here along with input file and result comment: $Computerlist = get-content "C:\temp\servers.txt" foreach ($computername in $computerlist) { Invoke-Command -ComputerName $computername -ScriptBlock {add-LocalGroupMember -Group "Administrators" -Member GIN } Write-host "ABC User added in $computername" }    

  Open the Powershell ISE → Create new script with the following code and run it. Get-ADObject -Filter 'Name -like "*"' | Where-Object {$_.ObjectClass -eq "user" -or $_.ObjectClass -eq "computer" -or $_.ObjectClass -eq "group" -or $_.ObjectClass -eq "organizationalUnit"} | Sort-Object ObjectClass | Export-CSV C:\Temp\ExportAD.csv -notypeinformation Open the file produced by the script in MS Excel.

 A technological change made in Windows 10 Anniversary Update caused a problem where webcams failed to work, and the respective software (like Logitech, Skype) simply hung up within minutes of use. Microsoft is working on an official fix that will be available in September. But, if you can’t wait a month before your webcam works properly again, there’s a registry hack you can use to re-enable the old behavior and fix this problem. First, open the registry editor by opening the Start menu, typing “regedit”, and pressing Enter. Then, navigate to the following key in the left sidebar: HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\Windows Media Foundation\Platform Right-click the “Platform” key in the left sidebar and select New > DWORD (32-bit) Value. Name the value “EnableFrameServerMode”. Double-click it and set the value to “0”. The next part depends on if you’re using a 32-bit or 64-bit version of Windows to perform this process. Not sure? If you’re using a 32-bit version of

  Having just created a new cluster, I noticed Event ID 1257 being logged in the Cluster Events node within Failover Cluster Manager. Cluster network name resource failed registration of one or more associated DNS name(s) because the access to update the secure DNS zone was denied. cluster Network name: 'Cluster Name' DNS Zone: *dns zone* Ensure that cluster name object (CNO) is granted permissions to Secure DNS Zone.    Here’s a screenshot of the actual events: The reason: Before creating the cluster, I had pre-added (manual) the DNS ‘A’ record for the CNO that I would need using IPAM. The solution: I simply deleted the CNO ‘A’ record in DNS and recreated it, ensuring that when I did so, I ticked, “ Allow any authenticated user to update DNS record with the same owner name ” If you do not manually pre-create the CNO 'A' record in DNS then you will not have this issue.  

We can use the Active Directory powershell cmdlet   Get-ADUser   to query users from AD. We can find and get a list of AD users who never logged in at least one time by checking the AD attribute value   lastlogontimestamp .   The below command lists all users who never logged on. Get-ADUser -Filter {(lastlogontimestamp -notlike "*")} | Select Name,DistinguishedName If you want to list only enabled ad users, you can add one more check in the above filter.   Get-ADUser -Filter {(lastlogontimestamp -notlike "*") -and (enabled -eq $true)} | Select Name,DistinguishedName If you are familiar with LDAP filter you can also find never logged in users by using ldap filter.   Get-ADUser -ldapfilter '(&(!lastlogontimestamp=*)(!useraccountcontrol:1.2.840.113556.1.4.803:=2))' | Select Name,DistinguishedName In most cases, we may want to find AD users who created in last certain days or months and not logged in their system. To achieve this, we need to fil

I had a set of Windows 2008R2 servers today that were having trouble backing up the system state via Windows Server Backup – they would fail with the error “System writer is not found in the backup”. I scoured the ‘net and talked to colleagues, and all of the resolutions I could find involved re-registering components, re-securing things in the Cryptography Service (prompted by CAPI or CryptSvc errors in the event log), setting ownership on WinSXS folders, etc. I did not have any such errors in my logs to indicate a permissions issue – in fact, I saw no errors at all (usually good – not so much when something is broken!). However, every time I ran “vssadmin list writers”, indeed the system writer was missing. After taking a procmon, I noticed that the last thing that was searched were some setupapi.ev* files in \Windows\Inf: I decided, on a whim, to replace these files with files from another server I had that was working – I stopped the VSS and CryptSvc services (th

I was researching how to change the Subnet Mask of a DHCP scope on a Windows 2008 server. It turns out you can’t change the subnet without deleting the scope and recreating it. If there are a lot of customizations to the scope, though, like reservations and scope options, it’s no easy task to delete and recreate the scope. Luckily   I found one page   that explains how to export the scope to a text file, make changes, and then reimport it. The whole process takes only a couple of minutes, and you end up with a deleted and rebuilt scope that has all your customizations intact. Use the below command to export the scope configuration Syntax: C:\>netsh dhcp server \\”Server name” scope “scope subnet” dump>c:\dhcp.txt Example: C:\>netsh dhcp server \\Test01 scope 192.168.1.0 dump>c:\dhcp.txt That creates a text file you can edit to change the Subnet, and whatever else you want changed. Then you have to delete the scope from the DHCP manager, and reimport the text