I needed to migrate a number of users and groups, not a large number so was easy enough to move them manually.

I thought I saw a while ago some automated tools to assist with migrating users and groups, but do you think I could find them again!

Anyway after a quick tweet of frustration Paul from Metacoda came through with a reply pointing me to:

Sample 42251: Partial Promotion of User and Group Metadata

Legend!

You have to go through the standard windows add/remove programs process for each SAS component/product, or restore a clean copy of the server image in the pre-install state.

(Now why would you do this multiple times you ask, well often becuase you have mucked up the install or you are trying to install a version of SAS that matches your client to test something for them or you)

SAS have issued a tech note that makes life so much easier:

Installation Note 39894: Using the SAS Uninstall Wizard to remove SAS® 9.2 from Microsoft Windows operating environments

The wizard assumes a raft of defaults that you will probably need to overide (i.e c:\) but provides parameter options to let you do this.

And of course if you are on Linux/Unix then there is no Windows registry to get in the way, so ignore the tool and just delete the files!

It was a great new interface to replace the old MRV.

It went through a few iterations, but not a lot changed (although I was always confused about which version could only open Cubes and whihc could open Cubes and Relational adata).

And then there was the SAS Web OLAP Viewer for .Net (SWOVN), always tricky in demo’s trying to decide which one to demo. showing both would always confuse people, especially as the both had different functionality.  (By the way the answer ended up being demo the Java one, unless the customers were a Microsoft bigets)

The goal of SAS development was always to roll the OLAP Viewer functionality into Web Report Studio, and after just completing a SAS BI 4.3 client upgrade it looks like it has happened.

In the upgrade notes it says:

“The product has been upgraded from Version 4.2 to Version 4.3.
The SAS Web OLAP Viewer application is no longer supported. It has been replaced by functionality that is available in SAS Web Report Studio 4.3.”

So SAS Web OLAP Viewer me old friend, thanks for all your help, and RIP.

Paul mentions it was probably lack of use that caused SAS to stop developing and supporting the replication capability, but im guessing that it was actually the fact that people used it and it didn’t work that caused the action.

Although replication was a pain to set-up, it seemed to be useful as part of the SAS 9.2 migration strategy, or alternatively intiating a new SAS environment.

What it was mean’t to allow you to do, was fully replicate an environment (say Development) to another Environment (say UAT or Prod) and automatically change all the pointers through the SAS environment to the new instance.  So for example automatically changing the name of the servers if you were moving environments across physical or virtual machines or changing userid’s, file paths, ports etc.

So for 9.2 migrations it made sense to create a blank Dev 9.2 environment, migrate the 9.1 production objects to it, test the Dev environment, then replicate the Dev environment upto UAT and Prod.

As Paul quite rightly highlights the only other option was partial migration, i.e exporting and importing SAS Packages and this option is not available for all SAS content (Portal pages and Portlets being one of them until BI 4.3 is out).  Its also a pain if you had to do it for 3 environments, not to mention the risk of the environments getting out of sync from day one (compared to day 99

I know of one NZ site that took the replication approach for their migration, but unfortunately found the replication process didn’t change all references during the process, and so the environments got a little confused (to say the least).  Nothing worse than Production updating files or objects in Dev it seems.

So maybe this was one of the few sites using replication, and therefore there wasn’t enough of a user base to warrant making it work properly, but it does worry me when functionality gets de-supported like this (just thankful i’m not in the middle of a SAS 9.2 migration project that was relying on this feature and hope your not either!)

The EG projects have a large bunch of custom code nodes (so hate those!) and they are all running some macro’s that use a date prompt.

Of course they work fine in 4.1 but fail in 4.2.

Traced it to a change in the way date prompts work in eG 4.2 via this SAS Support note:

Problem Note 36581: Date and Datetime parameters might cause syntax errors after project migration to SAS® Enterprise Guide® 4.2

Followed the fix below and updated the date variable in the code from &date to “&date”d  and the date is back on!

For example, in earlier versions of SAS Enterprise Guide, the correctly generated %LET statement might be %let datevar = '01jan2009'd;. However, after migrating projects to 4.2, the statement is incorrectly generated as %let datevar = 01jan2009;.

To circumvent the problem, open the query in 4.2 and edit the filter by adding quotes around the parameter. For example, use "&YourDateVar"d for dates, and "&YourDateTimeVar"dt for datetime parameters.

SAS Support article here:

http://support.sas.com/kb/22/194.html

Outlines how to migrate formats across SAS systems.

Basically you just:

1) Export the formats to a transport file by using the follwing code:

  libname library 'location-of-existing-formats-catalog';
  libname trans xport 'transport-file-name';
  proc format library=library cntlout=trans.cntlfmt;

2) Import the formats from the transport file using the following code:
  libname library 'output-library-for-format-storage';
  libname trans xport 'transport-file-name-from-sending-site';
  proc format library=library cntlin=trans.cntlfmt;

This is of course assuming you don’t have the code that originally created teh formats, because you could just run that instead. But bet you dont as you have just searched for something that made you find this blog post

Basically you just go:

PROC OPTIONS OPTION=FMTSEARCH;

And the format paths will be listed.

In addition Chris also mentioned:

“Next, EG maintains a cached list of formats that it gathers from the SAS server. To make sure that your new format has a chance to be detected, go to Tools->Options->Data: Data General, and look at the “SAS Formats/Informats Cache”. If the button is enabled, click “Clear cache”. It will be enabled only if you have already used EG to browse the list of available formats during the current EG session.”

Another EG button I didn’t know existed!

The process is:

• Copy the entire EM project structure to the new server (assuming you are going from like platform, i.e windows to like platform, i.e windows)
• In EM 6.1 create a new project and call it the same name as the one you copied and give it the same path
• When it tells you it already exists the accept the warning.

Wallah your EM project is now in SAS 9.2 / EM 6.1

(Warning you can;t send it back to EM 5.1)

I did strike a few gotach’s:

• I hadn’t migrated the SAS formats that the tables in EM model were using, so it didn’t import the tables, but also didn’t give me an error, they just didn’t show up.  Once i migrated the formats, it was fine (had to recopy the EM project files though)
• I got some horrendous SCL error when opening the Diagrams, so ended up deleting them, exporting them as xml objects in EM 5.1 and then importing them as new diagrams in EM 6.1