Showing posts with label Windows Server 2003. Show all posts
Showing posts with label Windows Server 2003. Show all posts

Wednesday, December 3, 2014

3 ways to get remote computers MAC address on Windows Servers or Workstations

There are many ways to get remote computers MAC address on Windows. In this post, I'd like to show 3 ways to get MAC addresses. To get remote computers MAC address, you need to have administrative credential on remote computers and make sure firewalls of computers or network don't block the connection between both computers.

Getmac
Getmac is a built-in command started from Windows XP to get mac addresses from a local computer or remote computer.

On "Command Prompt", perform "getmac /v /s <Remote Computer Name> /U <Remote or Domain User Account with administrative privilege> /FO <List, Table or CSV>" to get MAC addresses from a remote computer.


Enter the password of the account to get the result.

Remark: Both computers communicate with TCP port 135.

Windows Management Instrumentation Command-line (WMIC)
Windows Management Instrumentation Command-line (WMIC) is a command to work with WMI to get or modify the settings of a computer. In this case, I'm going to use wmic to get a remote computer MAC address.

On "Command Prompt", perform "wmic /user:<Remote or Domain User Account with administrative privilege> /node:<Remote computer name> nic list brief".


Enter the password of the account to get the result.

PowerShell
PowerShell is a good way to get information from computers. It's easy for administrators to learn and use. By the way, we can perform the following cmdlet to get MAC address from remote computers.

On "PowerShell" console, perform "Invoke-Command -ComputerName <Remote Computer Names> -Credential (Get-Credential) -ScriptBlock {Get-CimInstance -ClassName Win32_NetworkAdapter | FT Name,MacAddress -AutoSize}" on Windows 8, Windows 8.1, Windows Server 2012 or Windows Server 2012 R2.


Enter the user name and password with administrative privilege of the remote computer.


Remark: Get-CimInstance is a built-in cmdlet on PowerShell 3.0 or later. For Windows 7 or Windows Server 2008 R2, we can perform "Get-WmiObject -Class Win32_NetworkAdapter -ComputerName <Remote Computer Name> -Credential (Get-Credential)".


Enter the user name and password with administrative privilege of the remote computer.


Eventually, we got MAC addresses from above methods.

More information:




This posting is provided “AS IS” with no warranties, and confers no rights!

Sunday, September 21, 2014

Migrating File Servers in the same domain

How to migrate a non-DFS file servers? We will talk about the high level migration steps to migrate Windows File Server Role to a new Windows Server in the same domain.
 
First of all, make sure both file servers were joined to a same domain. Then, administrators can check which folders are sharing by using "Computer Management" or performing "net share" on "Command Prompt".
 
 
Remark: ADMIN$, IPC$, C$ are default share of file servers.
 
After that, administrators can perform "Robocopy" to copy the folder with NTFS permissions from old server to new server or use backup software to back up and restore the folder and file with the same NTFS permissions to a new server.
 
Then, we can export the share permission settings from the registry of the old file server. The registry path of share permission settings is the following:
 
HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\LanmanServer\Shares
 
 
Export "Shares" with "Security" registry key. After exporting the registry key, administrators might need to delete the registry settings which you don't want to import to new file servers.
 
 
Now, we can import the registry file to a new file server. After importing the registry key, we need to reboot the new file server to make share folder permissions effective.
 
When all NTFS and Share permissions are correct, we can stop sharing from the old file servers and then update the drive mapping to a new file server.
 
References:
 
This posting is provided “AS IS” with no warranties, and confers no rights!

Tuesday, September 9, 2014

Installing Active Directory Management Gateway Service for Windows Server 2003 and Windows Server 2008

Active Directory Management Gateway Server is Active Directory Web Service for Windows Server 2003 and Windows Server 2008. In Windows Server 2008 R2, Microsoft added Active Directory Web Service. One of features in Active Directory Web Service allows administrators to use PowerShell cmdlets and Active Directory Administrative Center to manage Active Directory. To use Active Directory cmdlets to manage Windows Server 2003 and Windows Server 2008, administrators have to install Active Directory Management Gateway Server on Windows Server 2003 or Windows Server 2008. Active Directory Management Gateway Server is a hotfix file. Administrators can download from here.

It's quite straightforward to install Active Directory Management Gateway Server. I will install it on a Windows Server 2008 domain controller.

Prerequisites
  • Download and install Microsoft .Net framework 3.5 SP1 on C drive of a Windows Server 2008 domain controller
  • Download and install KB969166 on C drive of a domain controller which will be installed Active Directory Management Gateway Server
  • Download KB967574 for Windows Server 2008 domain controller (without SP2 only)
  • Download KB969429 for Windows Server 2003 domain controller only
  • Download KB968934 on C drive of domain controller
Lab environment

  • 1 domain controller is installed Windows Server 2008 with service pack 2
  • 1 workstation is installed Windows 7 with Remote Server Administration Tools (RSAT)

Lab
1. On a domain controller, log in as Domain Administrator.
2. Launch "Windows Explorer" and then navigate to C drive.
3. Double-click "Windows6.0-KB968934-x64" to install the hotfix.


If Microsoft .Net framework 3.5 SP1 and KB969166 isn't installed, "Windows6.0-KB968934-x64" cannot be installed on a domain controller.

4. Restart the domain controller.
5. If installation is successful, "Active Directory Web Services" is added and started on the domain controller.


As a result, a Windows 7 workstation can perform Active Directory cmdlets to manage the Active Directory.


Reference:

This posting is provided “AS IS” with no warranties, and confers no rights!

Monday, September 1, 2014

Cloning Citrix presentation servers 4.0 to other Active Directory forest

Citrix presentation 4.0 isn't a new product in the market. Recently, I needed to perform a proof of concept for cloning Citrix presentation servers 4.0 from a production Active Directory forest to a testing Active Directory forest. 

Why do I need to clone Citrix presentation server?

Many applications were installed on Citrix presentation servers. However, I don't want to re-install all applications on new presentation servers. Finally, I tried to clone the servers.

In this post, I will talk about high level migration steps. Terminal Service licensing servers and Citrix licensing servers have been set up in both environment. 

I'm going to talk about what I did and which tools I used for cloning Citrix presentation server 4.

First of all, all Citrix presentation servers are virtual machines. It's easy for me to clone it. Before cloning Citrix presentation server, I checked "Add local administrators" and assigned "Full Administration" on "Privileges" window.




Then, I cloned the virtual machines which are installed Citrix presentation servers from VM level but I didn't perform sysprep for Citrix cloning.

After that, power-on the cloned virtual machines and logged in as local administrator.

Then, I preformed "chfarm" to create a new farm and change it to local store.



I launched Citrix presentation console to check "Add local administrators" and assign "Full Administration" on "Privileges" window again.

I used "Clone XenApp VM v1.0" to help me to do some tasks related to Citrix presentation servers. This tool can work with Sysprep or NewSID tools for generating new SIDs for Windows. For cloning Citrix presentation servers, I checked all options from "Clone Virtual Machine Tasks" and then click "Clone".



When cloning finished, I updated the IP address and join to new domain.

After joining domain, I used "Clone XenApp VM v1.0" to perform "Post-Clone Virtual Machine Tasks" for all Citrix presentation servers.

Then, I performed "chfarm" again to join the new Citrix farm on another Active Directory domain.

After that, I updated the local administrator option of Citrix presentation console again.

Finally, I could publish the applications on my cloned Citrix presentation servers on the new Citrix farm.

This post is based on my lab environment for proof of concept. I don't guarantee it works on your environment. All above steps are for your information.

This posting is provided “AS IS” with no warranties, and confers no rights!

Monday, August 18, 2014

Choose an appropriate Remote Desktop Licensing server for your environment

The latest Windows version can be installed the current and previous Remote Desktop Licensing or Terminal Services Licensing licenses in the server. For an example, Windows Server 2008 R2 can be installed Windows Server 2008 R2 and previous Remote Desktop or Terminal Services licenses in the server. However, Windows Server 2008 R2 cannot be installed Remote Desktop or Terminal Services licenses of Windows Server 2012 later because it cannot support the future version of Windows. To deploy the latest Remote Desktop environment, administrators have to install the latest Windows for Remote Desktop Services Licensing.

For more detail, please read "RDS and TS CAL Interoperability Matrix".

This posting is provided “AS IS” with no warranties, and confers no rights!

Tuesday, January 28, 2014

Update the Windows Time Service settings of domain member servers in Hyper-V virtual machine

Normally, Windows Time service of domain member servers synchronizes a domain controller in domain environment. However, domain member servers are under virtual machine environment (Hyper-V). Virtual machines synchronize them time with the Hyper-V host server because the "Time synchronization" of "Integration Services" is enabled in virtual machines.


To verify the setting, we can log in as local administrator of a domain member server and then perform the "w32tm /query /source".


Now, the domain member server is synchronizing the time with the Hyper-V host server.

According "Time Synchronization in Hyper-V", the "Time synchronization" of "Integration Services" should be enabled in virtual machines. However, administrators can update the registry in virtual machines to stop W32Time from using the Hyper-V time synchronization integration service for moment-to-moment synchronization.

Goal
  • Update the Windows Time Service in a domain member server, TM01, to synchronize a domain controller
Lab

1. On TM01, log in as Local Administrator.
2. Launch "Registry Editor".
3. Navigate to "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\W32Time\TimeProviders\VMICTimeProvider".
4. On right pane, double-click "Enabled".


5. Next to "Value data", change to "0".


6. Click "OK".


7. Close "Registry Editor".
8. Launch "Command Prompt" as administrator.
9. Perform "w32tm /config /syncfromflags:domhier /update" to update the setting to synchronize the time with a domain controller.


10. Perform "net stop w32time & net start w32time" to restart the Windows Time service.


11. Perform "w32tm /resync /force" to force synchronization.


12. Perform "w32tm /query /source" to verify the result.


As a result, the domain member server which is a virtual machine synchronize the time with a domain controller.

More information:

This posting is provided “AS IS” with no warranties, and confers no rights!

Sunday, January 12, 2014

The trust relationship between this workstation and the primary domain failed

When we use a domain user account to log in a workstation, we might get the following error.

"The trust relationship between this workstation and the primary domain failed".


This issue can be found on Windows 2000 to Windows Server 2012 R2 environment. How to make this error? Basically, Active Directory and workstations store 2 password versions of domain computer accounts which are "current password" and "previous password". If 2 password versions of this domain computer account don't matched the password copy of this domain computer account in Domain Controller, Windows displayed "The trust relationship between the workstation and the primary domain failed".  

By default, the machine account password changes every 30 days.


We can change this policy by Local Security Policy or Group Policy.

Some case will make this error.

1. The computer account was reset.


2. Administrators restore the backup or snapshot which is older than 60 days.

Quote from "Machine Account Password Process":

Now consider the scenario, when a machine is not connected to the network for a long period. Supposing on the client:
  • Old password = null
  • Current password = A
  • New random password = B
And on the machine account in AD:
  • unicodePWD = A
Remark: unicodePWD is a password copy of domain computer account

After 30 days when the Scavenger thread runs, the value would be:
  • Old Password = A
  • Current Password = B
At 60th day the same process happens again. So now  the newly generated password is C and the values are"
  • Old password = B
  • Current Password = C
Now when the client connects to AD, it will try the current password to authenticate. When that fails with error. Otherwise machine should be able to reset its password once it boots even after say 90 days.

End quote from "Machine Account Password Process":

There are 3 methods to fix this issue.


1. Disjoin and rejoin the computer to the domain.

Using this method, some services or applications cannot be started.


2. Perform "netdom resetpwd" to reset the machine account password in a domain computer.

According to KB325860, this procedure is most frequently user on domain controllers, but also applies to any Windows machine account.

I will try to perform it in my lab.

Lab environment
  • 1 domain controller named DC01 in contoso.com which is installed Windows Server 2012
  • 1 member server named App01 is a member server of contoso.com which is installed Windows Server 2012
Goal
Perform "netdom resetpwd" to fix "The trust relationship between the workstation and the primary domain failed" issue.


1. On DC01, log in as Domain Administrator.
2. Launch "Active Directory Users and Computers".
3. Locate "App01" and then right-click it.


4. Select "Reset Account".
5. On a pop-up window, click "Yes".


6. Click "OK".


7. Go to App01, log in as Domain Administrator.


Because the computer account has been reset, I cannot log in as any user of this domain. To fix this, we have to log in as Local Administrator and then perform "netdom resetpwd".

8. Log in as Local Administrator.
9. Launch "Command Prompt" as an administrator.


10. Perform "netdom resetpwd /s:DC01 /ud:Contoso\Administrator /pd:*" to reset and upload the local machine password to DC01 which is the domain controller.


11. Type the password of the domain administrator and then press "Enter".


12. Perform "nltest /sc_verify:contoso.com" to verify the trust.


13. Log out Local Administrator and log in as Domain Administrator.


As a result, the user can log in the workstation by using a domain user account.

Remark: There is no "nltest" and "netdom" command in some Windows versions like Windows Server 2003. You need to download and install the support tools before using it.

Remark: If you would like to reset a local machine password of a domain controller, please follow KB325860 to perform the additional steps.


3. Joe Richards, the MVP of Directory Services, wrote a detail article and a tool, MachinePwd, to fix this issue. If you are interested, please read his blog and follow his steps to fix it. 

References and more information:




This posting is provided “AS IS” with no warranties, and confers no rights!

Monday, September 9, 2013

Locate a locked Active Directory user account attribute by LDAP

In "Search and unlock an Active Directory user account by PowerShell", we can easily locate a locked user account and unlock it. However, I would like to know which attribute related to a locked Active Directory user account.

In order to find this Active Directory attribute, I tried to use "Ldp" to locate it.

Test environment
1) 2 user accounts in Active Directory users container named User1 and User2.
2) Enabled "Account Lockout Policy" by GPMC in my testing domain.



3) 2 Server named DC01 and MS01. DC01 is a domain controller and MS01 is a member server.

Lab
1. Log on and Log off User1 and User2 on MS01.
2. On DC01, log in as Domain Administrator.
3. Launch "Ldp" by performing "ldp" in a Command Prompt.


4. On the menu of "Ldp", click "Connection > Connect".



5. On "Connect" window, next to "Server", enter "localhost".



6. Click "OK".
7. On the menu of "Ldp", click "Connection > Bind".



8. On "Bind" window, click "OK".



9. On the menu of "Ldp", click "View > Tree".



10. On "Tree View" window, next to "BaseDN", select the domain directory partition.



11. Click "OK".
12. On left pane of "Ldp", expand "Domain name > CN=Users,DC=domain,DC=local".
13. Double-click "CN=User1,CN=Users,DC=domain,DC=local".



14. Double-click "CN=User2,CN=Users,DC=domain,DC=local".


We can all attributes of both accounts.

15. Try to use a wrong password to log in User1 on MS01 three times.
16. Back to DC01, double-click "CN=User1,CN=Users,DC=domain,DC=local".



There is a new attribute, lockoutTime, to be added in User1 and this value is greater than 0.


17. Launch "Active Directory Users and Computers".
18. Navigate to "Users" container, double-click "User1".
19. On "User1 Properties" window, select "Account" tab.
20. Check "Unlock account. This account is currently locked out on this Active Directory Domain Controller".


21. Click "OK".
22. Back to "Ldp", double-click "CN=User1,CN=Users,DC=domain,DC=local".


As a result, the attribute, lockouttime, was reset to 0. 

I assumed that If I use ldap to query the attribute of users, lockouttime, is greater than 0, user accounts are locked.

This posting is provided “AS IS” with no warranties, and confers no rights!