Greetings,

It can be a very varied procedure based on what your
environment looks like before and after. 
There is a KB Article that speaks somewhat to this procedure you can
find it here.

http://help.k2.com/en/kb001356.aspx

However a general outline of what you can expect to do is as
follows.

1.  Backup all
databases and all related K2 artifacts so you can roll back to a known good if
the move does not go well.

2.  Stop the old K2
server.

3.  Install K2 (same
version as currently running) on new K2 server. 
Point the installation at the existing databases.

4. Put in a hosts file entry or DNS entry to point old
server traffic to the new server. (this makes sure that processes in-flight can
get to the K2 server.)

5. Re-run configuration manager on all servers where K2
components are installed. (SharePoint, SSRS etc.)

6. Re-deploy all processes so that they pick up the new
server url/name

7. Test out functionality

8.  (Optionally) upgrade
to a more recent version

Keep in mind this is a high level overview of what is
required and there could be other steps necessary depending on your
environment, its processes etc.  I would recommend
engaging services from K2 or that of a partner who has some experience doing
this as this could save you lot of time and headache.

Hi Chris,

Thanks for the link and information, I am currently going through the process of migrating our K2 4.5 environment to Windows Server 2008 R2.

I pretty much followed the same process except where I have not rerun the setup manager on all relating servers, which I am doing now as I still have a few issues.

You mentioned you should redeploy all processes to update the URLs, but surely this would only effect new instances and not current ones so what is the benefit of this?

I do still have a problem where I am getting a repeating error in the log files saying it cannot connect to the old server. I have read I should remove an entry in the db but waiting for a response on my ticket first.

Also my ServiceObjects appear to be timing out when I try updating them, which I am still unsure how to solve.

Sorry if I have hijacked somebody elses post.

regarding the timeouts - check the connection strings of all service objects using smartobject service tester tool or from workspace

cannot connect error - you can delete the entry of old server in _server table. (make sure you have a backup of the database)

Regarding the following 

You mentioned you should redeploy all processes to update the URLs, but surely this would only effect new instances and not current ones so what is the benefit of this?

This is so all new instances of each process obtain all the up to date server info.

Hi Guys,

Thanks for the feedback. The Service Objects all have the correct connection strings, however the funny thing is that I am able to add a new instance fine. Whenever I try to refresh an instance I am greeted with errors.

I have removed the old server name and this has stopped the errors, however I am worried that all the references to the k2host server are recorded in the DB as the machine name and not the DNS entry we setup for this. "LUWINXX" instead of "k2host-tst.domain.com".

Does anybody know how I can easily change this globally as this is affecting authentication due to the SPN only delegating on k2host-tst.

Thanks for any help.

Chris, can you elaborate on #4? Our environment is 2 Sharepoint Web front ends, 2 Sharepoint AppServers, 2 Sharepoint DB servers, 1 Blackpearl server (w2003), and 1 Sqlserver for K2. Old K2Server name is NT2K2BPQA01, new one is WSQAK2BP01

I have had the SPNs reset for the k2 server account like so:

from
        K2Server/NT2K2BPQA01.emn.com:5252
        K2Server/NT2K2BPQA01:5252
        K2HostServer/NT2K2BPQA01.emn.com:5555
        K2HostServer/NT2K2BPQA01:5555
        http/NT2K2BPQA01.emn.com
        http/NT2K2BPQA01
        HTTP/QAMOC2.ECCDEV.COM
        HTTP/QATEAMAPPS
        HTTP/QATEAMAPPS.EMN.COM

to
        K2Server/WSQAK2BP01.emn.com:5252
        K2Server/WSQAK2BP01:5252
        K2HostServer/WSQAK2BP01.emn.com:5555
        K2HostServer/WSQAK2BP01:5555
        http/WSQAK2BP01.emn.com
        http/WSQAK2BP01
        HTTP/QAMOC2.ECCDEV.COM
        HTTP/QATEAMAPPS
        HTTP/QATEAMAPPS.EMN.COM

I have stopped the k2 server, installed Blackpearl on the new k2server (standalone), and will be running the k2 config on all 4 SP servers in about an hour. But I don't really know what to do for #4.

Hi Steve,

My assumption is that #4 was if you configured your K2 server as a farm and are using DNS A named to route traffic to the server it is installed on.

For example, we have the K2 service running on LUWIN90106.lu.domain.com and we have configured a A record in our DNS for "k2host-tst.intl.domain.com" which points to the IP on the machine. Our K2 environment is configured as a Farm which uses the "k2host-tst.intl.domain.com" as a FQN.

I believe point four is simply saying to update this DNS record to point to the new physical server. If you are only using the server name as a point you can ignore this as the settings will be updated with the new server name when you run the setup on each of the servers.

Hope this helps.

In this scenario I am speaking the idea that you have to replace the old servers DNS entry with the new servers ipaddress This is so that existing/running processes can complete since they still have the old server name.

ex

OLDK2Server = 192.168.1.1

NEWK2Server = 192.168.1.2

you will need to change the OLDK2server entry to point to the new server ip address like below

OLDK2Server = 192.168.1.2

Does this make sense?

It does make sense, but if the K2 server is configured as standalone wouldn't running the config on all servers replace the old name with the new? Where would the old name be embedded in existing processes?

I will request the DNS change tomorrow. I have been able to create new process instances but can't process existing ones. Also, I had created a new sharepoint page for workflow management (didn't want to expose everything in the K2 Portal Subsite) and added K2 Process management web parts. These no longer work ... getting a 404 not found when trying to view instances.

I also had to make changes to environment variables and string table entries, but that is expected.

And I had to run Brokermanagement.exe to find and fix the paths to dlls that it couldn't find. that is because the new server is a 64 bit and K2 installs in the c:program files (x86)... folder, and running the setup config on all servers didn't change that.

I need to do this in production soon, and I'm scared to death that I'll have problems that will greatly impact existing process instances (currently 301 active ones). If I have serious issues after attempting to do this, I assume that what I'll need to do is to restore the db from backup, stop the k2 service on the new server, and start the service on the old server. Is that all? That should restore the original string table, environment variables, and the items changes when I run brokermanagement, right?

I'm getting ready to deploy our largest workflow yet ... a rewrite of our original K2.net 2003 workflow ... and want to be sure the new server is in place so I can upgrade blackpearl to the latest version.

Sorry for the delay in response, this can be a fairly complicated matter have you considered opening up a K2 Answers ticket to get some advice and assistance?  Just a thought.  I'll try to answer the questions as best as i can here.

Running the configuration wizard on all the boxes will as you experienced work great for new processes but the old K2 server name is still present in all running workflows which is why in order for those to complete you should fool it by changing the DNS entry.

I would not do this in production till you have a very solid process down in a test environment and can successfully reproduce a successful outcome/result whereby all new workflows and existing workflows can be successfully actioned/accessed etc.  With respect to what would need to be done to rollback...you are correct in your assessment, at a high level that is exactly what needs to be done.  Ensure you have good backups of everything just in case you do need to roll back, during the migration ensure that the old server is turned off and cannot process any new workflows etc.  

Has anyone else out there in Underground land done this before that can chime in on some tips/tricks and share their experiences?