Pages

Friday, February 10, 2012

How to clone a Pharos Server for Development and Testing Purposes

Currently I'm working upgrade our Pharos 8.1 to 8.2 and thought I'd share how I first work out the upgrade process on a cloned VM of our production Server.
Disclaimer: Before we start, this process is at your own risk and is easy to make very harmful mistakes to your Pharos Environment. If your not clear on what your doing please stop and don't continue until you are clear you will not be harming anything. Also I'm betting this process is not recommend nor supported by Pharos Systems nor am I responsible for any loss or harm to your systems.
I'll note here this process isn't needed if you truly have a development environment that closely matches production and is completely isolated from your production environment. For myself while we have a development environment it doesn't have any were near the printers and clients to consider it a printing development environment. Ours is missing Mac clients because its primarily all VMware VMs.

Firstly clone the production Pharos Server or Servers VM, in and do not run VMware customization on the VM and don'ts power on the newly created VM. If your production Server(s) is not a VM you can do a Physical to Virtual create a VM of it.

Now I don't have the SQL Database on the local Pharos machine but in on a remote SQL cluster. Also there is a static IP Address assigned in the VM so its critical that the cloned VM not be allowed to talk on the production network at all until we're done making our changes. After the VM is cloned remove the Nic from the VM, you could just disconnect it but I want be very sure someone else doesn't reconnect it till I'm ready for it to talk on the network. Also this will allow us to be sure the new Nic doesn't have a statically assigned IP address settings on it.


Once your sure it can't connect to you network power on the VM. Change the OS computer name to something else, I usually use the same name of production server and add “dev” to the beginning of it. If the machine was bound to a domain please remove it form the domain as well and be sure you either know the local administrator password or like me change it to something easier to remember because we'll be using it.

NOTE: When say removing it from the domain we are telling the machine it is no longer thinking its a part of a domain. Since the machine is not connected to the network the domain has no knowledge of the change because it and shouldn't because the production VM Clone should still be bound to AD.

Copying the database
If production machines doesn't host the SQL Database local we'll need to copy the production one in order to not corrupt the production DB when we start the Pharos Servers.

The question is whether we move the Pharos database it to the Dev. VM or to another SQL server. If we want it to be hosted on the the Development Pharos Server we just created we first need to get on the network.  But in order to do that safely we need to make sure that none of the Pharos Services are running.

This is the route I'll going to use here, as when we have everything done in can undo the entire upgrade process via a snapshot on the VM. So Power on the development Pharos server, again we still shouldn't have any networking and disable all the Pharos services.


Now Shutdown the VM and add a NIC because I want to make sure doesn't have a staticly assigned IP address settings on it. The VLAN of the NIC I'm using will have DHCP address handed out so I won't need to set one; your network may be different.

I also take a snapshot here while I have the VM powered off, In the Snapshot notes in say that the OS is renamed, if SQL isn’t install yet and that the pharos services are disabled. The snapshot can be useful if something goes wrong.

Now bind the Development VM back to the domain and reboot.

Install Microsoft SQL Server on the development VM. You can likely use express or the Evaluation but I'll be installing the full Microsoft SQL Server 2008 because I have it. Not going to walk through the setup of a SQL server because if your doing all this I'm hoping that part will be easy to understand. But I did take some notes on issues that can arise here on it and may make a post on it soon.

Once the SQL Server is running you should be able to use Microsoft SQL Server Management Studio to right click the production database, and choose copy database. Enter the source and destination servers.

Warning: when the Select Transfer method be sure to use SQL Management Object method unless its ok to take the production server Database off line.

Chose enter the check box to copy the Pharos database.


Be sure Logins and Stored Procedures are in the Selected Server Objects.

Click next, choose Run Immediately and continental until you can click Finish. Check the settings and if everything looks good click Finish.

If everything goes correctly and you should be able to navigate the development pharos VM and connect to the DB we copied over. Open a few tables and make sure everything looks correct.

 
Power off the development VM and take a snapshot. Next We'll be modifying the Pharos registry which we can easily mess up so as snapshot makes recovery easy.

Modifying Pharos to use the Copied Database that moved locations

We should at this point have a VM with all the pharos services disabled and the pharos database installed locally. We now need Pharos to use the new database location and the pharos server name change. This is done mostly by modifying the registry anyplace we find the old server name and replacing it with the new development server name.

Note: To make this document easier to follow I'm going to assume the development VM name is "DevPharosserv1" and that original server name was "Pharosserv1". You may have change this based on your own environment.


Open the Registry Editor and navigate to the following location dependent on the CPU type:

64bit: KEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\Pharos
 32bit: KEY_LOCAL_MACHINE\SOFTWARE\Pharos


Under "..\Pharos\License Server" change HostAddress from "PHAROSSERV1" to "DEVPHAROSSERV1".

Under "..\Pharos\Database Server" change HostAddress from "PHAROSSERV1" to "DEVPHAROSSERV1".

In the "..\Pharos\Database Server\Database"on change Server Name to "devpharosserv1" or to where ever you moved the Pharos database. you may also need to change the username and password if they are different due to the database move. In fact go ahead and connect to the database using the username and password given in the registry keys. I found that the SQL account listed in the registry had been disabled and i had to enable it and then reset the password to match that in the registry.

Don't continue until you can connect to the database with Microsoft SQL Management Studio using the same username and password in the registry. you can change the registry to something that will work but I didn't have to.

Starting the Pharos Services

Now disable the network adapter. We want to start the pharos services and since everything is now local to the server we shouldn't need a network connection and if we did do something wrong it won't affect production. If you are setting up multiple servers and then you can't really have them off line. Be careful and be sure what you change and what machine you are working on. I *may* have once thought I was a development VM and changed the registry settings of our production Pharos at few years ago.

After the Network adapter is disabled, select the Pharos License Server Service and start it.
Followed by the Pharos Database Service.

If Pharos Database Service takes more than 10 seconds to start and then times out there is most likely a problem with its values in "..\Pharos\Database Server\Database". More detailed information is available in the Windows Application Event log.

If Pharos Database Server is started continue enabling the rest of the Pharos Services but leaving Pharos Print Server alone.

I also left Pharos Billing Gateway off for now. You'll have to make that call on that service your self. I've written a exe replacement for testing what our CBord would return. I may post later

Before we can start we need to modify the Pharos Database servers table. Right click the table and choose edit. Then change the hostname of the server to the new hostname.



When starting  Pharos Print Server  if it fails check the Windows Application Event log. If you see:


[PSService::Run] Caught an exception with message 'Print Server '127.0.0.1' not in database'

If might not of changed the hostname correctly. Go back to the table and check again.

Now try to start the Pharos Print Server  Service now; it should start.

Configure the Rest in Pharos Administrator


Open Pharos Administrator and it should let you in same as always. Check the System -> Server Configuration and ensure that the development server is listed and all services are running. If so we can continue.

Open Packages and then Packages Global Settings and change all the paths to use the devlopment hostname and then do a change control.


Now you'll most likely have to enable the network adapter and then rebuild the Pharos Packages. This could may take a bit to finish depending on how many Packages you have. for me 7 packages took about an hour. Optionally you could delete the packages instead of rebuilding them by following the path listed in the Packages Global Settings.

Pharos Billing Gateway
You'll need to decide what to do with the Pharos Billing Gateway. For some tests you may want to use it, for others you may want it completely disabled so it can not affect production systems. I'm going to change mine to point the the development server. but you could point to to no ware if wanted to make sure that it failed.

 
If you do point it to the development server or don't change it be sure you the Gateway it pointing at configured. I can't really provide much input here because there are so many types of gateways in I've only worked with the CBord/Odyssey Gateway. Use your own judgment here and be careful.


Complete

At this point you have completed creating the Pharos Environment clone. All that is left is to shut down the VM and take a snapshot of the development VM. We want this to revert to if something goes wrong while testing on this VM in case of an error our part or failed Pharos Upgrade.

If this all works you should be done. Do some tests like crediting a users account then check your production system to check that it wasn't affected. Also you can install one of the packages and then check which system logged the print job.

1 comment:

  1. Amazing, I was just going to attempt this myself. Great info. If only pharos provided this sort info.....

    ReplyDelete

Please leave a comment; someone, anyone!