Monday, June 2, 2014

Export Active Directory Group Membership to CSV

Using Windows PowerShell you can easily export Active Directory group membership to CSV. First, start Windows PowerShell as an administrator and import the Active Directory PowerShell module.
Import-Module ActiveDirectory
Next, run the below command where "GroupName" is the name of the group you want to export the membership list.
Get-ADGroupMember -identity “GroupName” | select name | Export-csv -path "C:\results.csv" -NoTypeInformation
If you have nested groups you will see the nested groups and not the members of those groups in the results.csv. If you want the members of those groups exported use the command below.
Get-ADGroupMember -identity “GroupName” -recursive | select name | Export-csv -path "C:\results.csv" -NoTypeInformation
If you have a question or would like to make a request for something you would like to see on my blog feel free to reach out to me.

Thursday, May 22, 2014

How to find and cleanup large files in Linux

Today I received an alert a linux system was low on free space. Using the below command I found "/dev/mapper/VolGroup00-LogVol00" had 4% available space.
[root@centos ~]$ df -h
Filesystem                         Size   Used   Avail   Use% /dev/mapper/VolGroup00-LogVol00    14G    13G    548M    96%
The "VolGroup00-LogVol00" is a directory mapped as a volume used for logging. If you do not know where the logs are you can use the below command to find the large directories. You can also use a larger depth setting but the output will quickly become too much to show on the screen. As you can see below the /usr directory is 11 GB in size.
[root@centos ~]$ du -h --max-depth=1
8.0K ./mnt
541M ./lib
8.0K ./srv
52M ./etc
36M ./sbin
35M ./boot
84K ./tmp
26M ./tftpboot
0 ./proc
0 ./sys
68K ./home
0 ./misc
11G ./usr
0 ./net
241M ./var
8.0K ./media
28M ./lib64
76K ./dev
12G .
The log space consumed turned out to be logs used by a web service. The service created one log file per day and no cron jobs were setup to clear the logs. Once I determined where the logs were located I ran the below command to clear out logs files older than 100 days where part of the log names began with the word "server".
[root@centos ~]$ find /usr/local/service/logs/server* -mtime +100 -exec rm {} \;
If you find there is one long giant contiguous log instead of many individual logs you can trunk it. First you need to rename the file with the below command.
[root@centos ~]$ mv service.log service.log.old
Now, copy the last 100 lines of the log to a new log file.
[root@centos ~]$ tail -n 100 service.log.old > services.log
If you find the log was fed from the head instead of the tail you would copy the first 100 lines instead of the last 100 using the command below.
[root@centos ~]$ head -n 100 service.log.old > services.log
Next review the new log to ensure the events are recent.
[root@centos ~]$ cat service.log | less
If it looks good remove the old log.
[root@centos ~]$ rm services.log.old
Finally confirm free space has been recovered using the below command once more.
[root@centos ~]$ df -h
Filesystem                         Size   Used   Avail   Use% /dev/mapper/VolGroup00-LogVol00    14G    6.0G   7.0G    47%

Wednesday, February 19, 2014

Detatch database failed for Server 'SQL-SERVER'. Error 3703

While trying to dismount a database I ran into the error: Cannot detach the database 'Database Name' because it is currently in use. (Microsoft SQL Server, Error: 3703).

This almost always happens due to an open connection which you can drop during the detachment process, but I like to exclude that option. This helps determine if the database still has connections to anything. There are two queries you can run that will tell you what is connected to the database. First run the below query.

select * from sys.sysprocesses where dbid = db_id('Database Name')
The returned results will display a host name, and a login name. Using the two you can determine if the connection is initiated locally, or externally. If externally, simply go to the server that is connecting to it and remove any User or System DSNs. If none are listed the database is likely configured inside of an application. Refer to your documentation for whatever application resides on the server in order to remove the database connections.

If you find that the connection was initiated locally, you will need to run the below query. This query provides information about current users, sessions, and processes in an instance of the Microsoft SQL Server Database Engine. The information can be filtered to return only those processes that are not idle, that belong to a specific user, or that belong to a specific session.

Using the status, loginname, hostname, dbname, and cmd fields you can likely determine what process is locking the database locally. In almost all cases I've seen it is due to a backup, transaction log shipping, or some other type of SQL related task.

If you've managed to track down the culprit and removed the connection to the database you should now be able to proceed with detaching the database without dropping open connections. For more information about SQL sp_ commands click HERE.

Monday, February 17, 2014

How to configure a CentOS Linux Server in 5 steps

Below is a quick tutorial on how to setup a new CentOS server with basic settings quickly. I will also show you how to lock down SSH to secure the system. However, this is by no means a complete list of instructions for securing the CentOS operating system. We will create a basic non-super user, lock down SSH, configure the firewall, and set a static IP address.

1. First let's set the root user password.

[root@localhost ~]# passwd
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
2. Now let's create a basic non-super user and set the password
[root@localhost ~]# adduser newusername
[root@localhost ~]# passwd newusername
Enter new UNIX password:
Retype new UNIX password:
passwd: password updated successfully
3. Next let's edit the SSH configuration.
[root@localhost ~]# vi /etc/ssh/sshd_config
Here we can configure SSH to use a custom port and restrict SSH access so the root user cannot login. You will also need to restart the ssh service for the changes to take effect. Use :wq to save the configuration when finished.
# Prevent root logins:
PermitRootLogin no

#Port 22
Port 123
You can restart the sshd service with the command below.
[root@localhost ~]# service sshd restart
4. Next we need to edit the iptables configuration so the server will accept traffic on the new SSH port. Use :wq to save the configuration when finished.
[root@localhost ~]# vi /etc/sysconfig/iptables
While in the iptables config you should see a line referencing port 22 already. Change the port to the new port we set previously.
-A INPUT -m state --state NEW -m tcp -p tcp --dport 123 -j ACCEPT
If you wanted to restrict access to a network such as, edit the line as shown.
-A INPUT -s -m state --state NEW -p tcp --dport 123 -j ACCEPT
For the above changes to take effect you must restart the iptables service.
[root@localhost ~]# service iptables restart
5. Now, let's configure an ip interface as the last step. Use :wq to save the configuration when finished.
[root@localhost ~]# vi /etc/sysconfigc/network-scripts/ifcfg-eth0
Here you can edit the relevant settings as needed.
Now restart the network service and you're set!
[root@localhost ~]# /etc/init.d/network restart

Resetting Windows Passwords

Recently I received the below request for help through the Contact Me section of my blog.

"Hi vTechie, I have a situation with a VM in my vSphere environment. We lost admin access to the VM (XP) and are unable to get back in. The machine has lost domain connectivity and we are unable to login as a user with cached credentials. We do not know when computer lost domain connectivity. Please help!"

This is a strong case for why you want to use linked clones in VMware View and Persona Management. VMware View and Persona Management together make virtual machines disposable and all of the user data is stored on a server instead of on the VMs. In this case when a VM has an issue you can set VMs to automatically refresh (reimaged) or you can do it manually. This prevents the need to fix broken VMs and generally makes life easier for both admins and users alike.

To answer the original question you must reset the user password you are trying to login as or login as a domain admin to regain access to the VM. If the domain trust relationship on the VM has been broken you must login as the local Administrator account to rejoin the computer to the domain. Again, this is not required if it is a linked clone. In that situation you would refresh or recompose that particular VM. If you do not know the local Administrator password you must reset it.

There is a boot disk you can download called Hiren's BootCD. Simply download the ISO and boot into the password recovery environment to reset the local Administrator password. You will also likely need to boot the VM into BIOS to move the CD Rom up in the boot order. In order to "Force BIOS Setup" right click the VM and select edit. Then click the Option tab at the top as shown below, and check the box for "Force BIOS Setup".

Once in the password recovery environment follow the instructions on the Hiren's BootCD website to unlock the local Administrator account. Once you've successfully logged in as the local Administrator you can rejoin the computer to the domain or recover user data.

If you have a question or would like to make a request for something you would like to see on my blog feel free to reach out to me.

Thursday, February 13, 2014

How to Install the VMware Tools on CentOS

It is very important that you install VMware Tools in the guest operating system. With the VMware Tools installed VMs support significantly faster performance, time synchronization, and other enhanced features. Below are the steps to install the VMware Tools on CentOS.

1. Install the prerequisites into your CentOS. If asked any questions take all of the defaults.
[root@localhost ~]# yum install perl gcc make kernel-headers kernel-devel -y
2. Next attach the VMware Tools using the vSphere client.

3. Mount and extract the VMware Tools to a temporary location.
[root@localhost tmp]# mount /dev/cdrom /mnt
[root@localhost tmp]# cd /mnt
[root@localhost tmp]# ls
VMwareTools-8.3.7-341836.tar.gz  yum.log
[root@localhost tmp]# mkdir /etc/temp1
[root@localhost tmp]# tar xzvf VMwareTools-8.3.7-341836.tar.gz -C /etc/temp1/
4. CD to the directory where the tools were extracted and start install.
[root@localhost tmp]# cd /etc/temp1
[root@localhost temp1]# cd vmware-tools-distrib
[root@localhost vmware-tools-distrib]# ls
bin  doc  etc  FILES  INSTALL  installer  lib
[root@localhost vmware-tools-distrib]# ./
5. During the install take all of the defaults, then reboot your VM. Enjoy!

Thursday, January 30, 2014

VMware SRM: The guest operating system 'centos64Guest' is not supported

Recently, I ran a test of a SRM Recovery Plan for a new set of Linux VMs I inherited. The first test didn't go so well and returned the error "Error - The guest operating system 'centos64Guest' is not supported". After doing a cleanup of the test Recovery Plan, I ran the test again but this time without the IP setting customizations which allowed the test to complete successfully. I also had to alter some of the timeout settings, but that is pretty typical of VMs that take a long time to boot or require extra time to customize.

I selected a few VMs to test with and I changed their IP addresses manually. I needed to do this to test applications they were hosting to confirm the DR test was successful. However, somewhere along the way I had to reboot one or more of the VMs and the IP settings had reverted. After further investigation, I confirmed the reason why was the VMs were using network scripts to set network configurations such as MAC, IP, gateway, etc. Linux network scripts are typically stored at /etc/sysconfig/network-scripts/ and are named similar to ifcfg-eth0 where eth0 is the name of the ethernet adapter.

The first thing I did was to take a look at the network configuration scripts and document the existing settings. To do this, I ran the command:

cat /etc/sysconfig/network-scripts/ifcfg-eth0 | less
If the list is small and can fit on the screen you do not need the "| less" at the end. A sample of the of the network script output is below excluding any sensitive information.

Now knowing the VMs were configured via scripts I had to forgo using SRM IP customizations and instead use SRM's ability to run a script or command post power on for each VM that encountered the problem. First I had to create a directory on each VM to store the ifcfg-eth0 network script with the new network settings along with a script to replace the existing network script. To do this login to the Linux VM as root and run the commands below.

1. Create the needed directories

cd /etc
mkdir srmipchanges
cd srmipchanges
mkdir dr
cd dr
2. Create the network script

    A. While in the DR directory, type the command "vi ifcfg-eth0" and hit enter.
    B. Type "i" to enter edit mode, and adjust the values below as needed.

    C. Hit ESC to exit edit mode, then type ":wq" and hit enter to save the file.
    D. Check the network script by using the command "cat ifcfg-eth0".
    E. If it looks good type ":q!" and hit enter to exit the file.

3. Create the script to replace the network script

    A. While in the DR directory, type the command "vi" and hit enter.
    B. Type "i" to enter edit mode, and type the values below.

/bin/cp -p /etc/srmipchanges/dr/ifcfg-eth0 /etc/sysconfig/network-scripts
/sbin/init 6
    C. Hit ESC to exit edit mode, then type ":wq" and hit enter to save the file.
    D. Check the network script by using the command "cat".
    E. If it looks good type ":q!" and hit enter to exit the file.

4. Configure SRM to run the script

    A. Using the vSphere client go to Home, Solutions and Applications, Site Recovery.
    B. Click Recovery Plans in the left pane, and select the recovery plan you are trying to test.
    C. Click on the Virtual Machines tab.
    D. Right-click the virtual machine and click Configure.
    E. Select Post Power On Steps in the left pane, and click Add.
    F. Select Command on Recovered VM.
    G. For the name box, type a name. I used the name "IP change".
    H. In the Content text box, type “/bin/sh /etc/srmipchanges/dr/".
    I. Adjust the Timeout settings to 10 minutes to accommodate for the needed changes.
    J. Once done click OK to add the step to the recovery plan.
    K. Click OK again to configure the VM Recovery Properties.

Repeat the steps above for each VM within the recovery plan as needed, and rerun the test Recovery Plan. This time the test should complete successfully and the VMs should be using the new IP addresses. You may also want to check the VMs host file as it is common to see an entry in there for the old IP pointing to the localhost or host name of the Linux machine. If it does, you will need to also script the replacement of the of the hosts file with the needed changes.

Monday, January 20, 2014

Cisco VPN client Windows 8.1 - Reason 442: Failed to enable Virtual Adapter

When you install the Cisco VPN client on Windows 8.1 you will likely receive the message "Reason 442: Failed to enable Virtual Adapter." when you attempt to connect to a VPN.

The fix is quick and easy. You do not even need to reboot. Open regedit and browse to the key "Display Name" located at "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\CVirtA".

Open the key "Display Name" and the value should be "@oem54.inf,%CVirtA_Desc%;Cisco Systems VPN Adapter for 64-bit Windows". To resolve the error first mentioned you need to edit the key to exclude "@oemX.inf,%CVirtA_Desc%;" leaving only "Cisco Systems VPN Adapter for 64-bit Windows". Try your VPN connection again and the issue should be resolved.