Configuring Virtual Networks

Here comes another article which is really descriptive..

 

http://technet.microsoft.com/en-us/library/cc816585.aspx

Network Configurations for Live Migration

The following technet article will come in handy when you deploy Hyper V clusters which involve Live migrations.

http://technet.microsoft.com/en-us/library/ff428137%28WS.10%29.aspx

Unable to delete agentless systems

I came across this article when i was having a hard time removing my orphaned cluster  from agentless monitoring..
http://opsmgrunleashed.wordpress.com/2007/06/04/unable-to-delete-agentless-systems/

Powershell remoting

Along with Windows server 2008 came powershell, a powerful scripting and an automation platform. With later versions of windows server, powershell came up with improved functionality and gaining raw power and its here to stay. Accept it or prepare to fall back in techie world! :)
In this post I will be sharing my experiences with power shell remote capabilities.okay lets move on.

Powershell remoting allows to run individual commands or to access full powershell sessions on remote systems similar to SSH. Powershell remoting is disabled by default (well…obviously! :P) and needs to be enabled. this is easy on domain joined computers but a bit more complex on workgroups but hey! this aint rocket science!

Enabling Powershell remoting
Fire up an elevated powershell session. (Right Click and run as admin). and run the following cmdlet.

enable-psremoting –force

This will result in enabling WinRm service, setting it to start automatically with the system and creates a firewall rule for incoming connections. –force switch will enable these settings without prompting the user for each step. If the PCs are domain joined, this is all you have to do and you are good to go for remote powershelling.



Workgroup Settings

If the computers you need to do powershell remoting is in a work group, you need a few extra steps as given below.
First, run the  enable-psremoting -force command on an elevated powershell on the computer you want to initiate connections from. So that both ends are now remote enabled!

Configure trustedhost settings on both computers so that they trust each other. The following command, for an example, trusts any computer and is suitable for a setup like a home network. you may replace the “*” with a comma separated list of computer names or IP addresses to restrict access.

Set-Item wsman:\localhost\client\trustedhosts *
on both computers.

Restart the WinRm service for the settings to take effect.

Restart-Service WinRm



Testing Connections
Run the following command on the computer your are connecting from to check what you did was successful. Replace COMPUTER with the name of the remote computer. The command will test if the winrm services is running successfully on the remote computer.

test-wsman COMPUTER

The successful completion of this command ensures WinRm is enabled and computers can connect.



Thats it!! lets run a few commands or start a remote powershell session!!

Run an individual command using invoke-command

invoke-command –computername COMPUTER –scriptblock {COMMAND} –credential USERNAME

Replace COMPUTER with the remote computer name or ip address, COMMAND with the command you want to run and USERNAME with the user name of the remote computer. The following screen cap shows get-host output on a remote computer.



Enabling a powershell session allows you to run multiple commands instead of a single command. You can initiate a remote powershell session using the following command.

enter-pssession –computername COMPUTER –credential USER



Replace COMPUTER and USER with the hostname of the remote computer and the username which you hope to log on with. type exit anytime you wish to log out of the remote session.

Export DHCP database from Windows Server 2003 or 2008

Following post explains how to migrate your DHCP database to a new server.

• log on to the source DHCP server. Note that the account must have local admin privileges
• Fire up an elevated command prompt and enter the following command
• netsh dhcp server export c:\dhcp.txt all
• copy the created text file to the destination server.

Install the DHCP Server role on the destination Server using add roles wizard from Server Manager. You do not need to configure any scopes.

• Log on to the destination server with an account which has local admin privileges.A user account in a group that is a member of the local Administrators group will not work. (My destination server was a Domain controller and i logged in as administrator :P )
• assuming that the exported text file was copied to C:\, fire up and elevated command prompt and run the following command. Make sure the DHCP Server service is running.
• netsh dhcp server import c:\dhcp.txt all
• Open the DHCP console on the new server and you may see the server with a red arrow pointing downwards. This new server has not been authorized yet!
• Right click the server and select Authorize.
• check whether you have all your scope options and Reservations in the new server.

On your old server, Unauthorize the DHCP server, Stop and disable the DHCP Server service from the services snap-in.

CAS Array configurations for Exchange 2010

Came across this while I was having a time getting to know Cas arrays and NLBs!

http://eightwone.com/2010/01/27/exchange-2010s-cas-arrays-nlb/

Redhat agent deployment failure Ops Manager 2012 SP1

Adding more some spice to work, my second agent deployment failed with the following error!

Agent verification failed. Error detail: The server certificate on the destination computer (redhatfs.mydomain.local:1270) has the following errors:
The SSL certificate could not be checked for revocation. The server used to check for revocation might be unreachable.
The SSL certificate contains a common name (CN) that does not match the hostname.
It is possible that:
1. The destination certificate is signed by another certificate authority not trusted by the management server.
2. The destination has an invalid certificate, e.g., its common name (CN) does not match the fully qualified domain name (FQDN) used for the connection. The FQDN used for the connection is: redhatfs.mydomain.local.
3. The servers in the resource pool have not been configured to trust certificates signed by other servers in the pool.

The server certificate on the destination computer (redhatfs.mydomain.local:1270) has the following errors:
The SSL certificate could not be checked for revocation. The server used to check for revocation might be unreachable.
The SSL certificate contains a common name (CN) that does not match the hostname.
It is possible that:
1. The destination certificate is signed by another certificate authority not trusted by the management server.
2. The destination has an invalid certificate, e.g., its common name (CN) does not match the fully qualified domain name (FQDN) used for the connection. The FQDN used for the connection is: redhatfs.mydomain.local.
3. The servers in the resource pool have not been configured to trust certificates signed by other servers in the pool.

The common name in the certificate received from my redhat server was not correct. why??
due to my carelessness, in my first attempt, I had tried to deploy the agents BEFORE creating the DNS host record! When this happens, the agent on Redhat Server sends a certificate with localhost as the CN for the Management Server to sign and verify. Correcting myself, I created a DNS record for the Redhat server and tried redeploying the agent but no luck while the same error kept coming up.

I removed the Opsmanager agent in Redhat but still no luck.

command: rpm –e scx

trying to solve the issue, I came across the following article on how to change the CN of the certificate presented to the management server.

http://technet.microsoft.com/en-us/library/dd891009.aspX

Eventhough you remove the scom agent on linux, it will not delete the old certificates. you need to change the values of CN to the FQDN of the redhat server. Deleting the files deployed by the agent will work. These files are located in /etc/opt/microsoft/scx folder.

agent deployment for linux servers are not as straight forward as windows servers. Check you covered up your prerequisites! click here for the steps.

I changed the CN to the hostname of the redhat server and tried agent deployment again. and it did succeed!!

Called it a day!