Tag Archives: system
This is John again with the Implementation team. Today, I want to look at another aspect of the ArcGIS 10 release: upgrading your server.
I’d like to start by reiterating Mostafa’s point from his earlier blog post – the best preparation for a major software upgrade is “testing, testing, and more testing”. This is especially true for server products, as quality of life for System, GIS, and DB Administrators is often determined by uptime. As a rule of thumb, try not to make any changes to the production environment that haven’t already been tested on a low-impact system. At the very least, perform upgrades at a time when you’ll be able to troubleshoot and fix any issues without impacting your organization.
Second, I’d like to mention some files and folders that are important to ArcGIS Server. It’s great to have a full system backup, but it can also be helpful to back up these specific items so they can be restored without rolling the entire system back. ArcGIS Server stores configuration files, map services, and security settings in C:Program FilesArcGISserver. When backing up, feel free to ignore the serveruserlog folder – it can become huge depending on how you have logging configured. These same folders can come in handy when reinstalling or migrating to a new system.
It’s a good idea to have a backup of your web content. There are too many variables to list everything in a blog post, but here are a few resources on migrating web applications that should outline what you’ll need:
- FAQ: What directories should be backed up for ArcGIS Server for the Microsoft .NET Framework?
- HowTo: Reconfigure ArcGIS Server 9.2 .NET after the host name has been changed
- HowTo: Move a ArcGIS Server .NET Web application to a new Web server machine
- EDN: Developing Web Applications with the Web ADF, Licensing and Deployment
One last note – the best, most complete information on migrating can be found on our Web site. Here are a few resources to look at before upgrading:
-John P, Senior Implementation Support Analyst, Esri Support Services
Hi there! I am Cheryl, Senior Support Technical Lead in the Geodata Support Unit at ESRI Support Services. Some of you may be wondering why we always ask for your configuration information. Delay tactic? No, guess again… Well, there are 2 reasons.
The first reason is that we want to ensure that you are using one of the supported configurations. Supported configurations are configurations on which the software has been certified to have been tested.
Does this mean that we do not assist you if you are running on an unsupported platform?
Not at all! We will still work with you as much as possible to resolve the issue, until it has been determined that the problem is definitely with the configuration. The issue would generally be tested on a supported configuration as close as possible to your specific configuration. If it is not reproducible, then chances are that the problem is configuration-specific. If we are able to configure – within reason of timeframe and resources – a test machine with your specific configuration, the workflow is tested on that configuration. Additionally, during software development or testing, there may be major problems encountered with specific system configurations. If these issues are beyond our control, for example, Operating System or RDBMS specific issues, we consider the platform to be unsupported. If those particular issues are subsequently resolved by the particular vendor, we may later revisit the configuration for supportability. If a problem is a result of an unsupported configuration, we do request that customers install the software on a supported platform, after which we will follow up to ensure that you are no longer experiencing the problem. Information on supported platforms is available at ArcGIS Server 9.3/9.3.1 System Requirements and ArcGIS Server Pre-9.3 Systems Requirements for versions prior to version 9.3.
The second reason is that some issues experienced by our customers end up being specific to a particular configuration. In Support, we will always try to reproduce problems following the workflow you provide. Not having the configuration you are experiencing the problem on results in us trying to reproduce on the most available configurations in Support. This can result in longer resolution times as various common configurations are tested in an effort to determine what the issue is. There are so many possible supported configurations that we may possibly miss your specific configuration in our tests; it is impossible to test a problem on each of the vast configuration permutations available. Providing us your exact system configuration can greatly reduce resolution time, as we now have the exact configuration for testing the workflow. Once the problem is reproduced, we still test on the most common configurations to see if the issue is also reproducible there.
Testing on multiple platforms/configurations – why?
Why do we go through the trouble of testing on other configurations? We are always forward thinking. The premise is that if one person experiences a problem, others may also encounter the problem. So in trying to resolve the issue, it is important for us to have the issue resolved across as many platforms as possible.
There may be situations where customers report that an issue is reproducible regardless of the configuration. While this may be so, it is still important to us that we have a frame of reference for resolving the issue, especially for the customer reporting the issue. When a problem is reported and it is determined to be a bug, the configuration for the customer(s) reporting the problem is included in the bug. To ensure that when we arrive at a resolution, those configurations are included in the tests of the resolution.
Solutions already available to you
In some situations, there are issues that have been resolved by a Service Pack or Patch, released subsequent to your current configuration. In these circumstances, we will compare your software configuration information with the bug fix release information. If it is determined that you do not have the Service Pack or Patch installed, we can point you to the software update on our Service Packs and Patches gateway: ESRI Service Packs and Patches Gateway.
- Having said that, allow me to make a pitch for always keeping your system updated with the latest Service Packs or Patches. So, go ahead and bookmark the above link, and return to it periodically to see what updates are available.
So when you are reporting an issue to us, please provide us your full configuration information so that we can arrive more quickly at a reproducible case and a subsequent resolution for your environment at minimum. Now that you are aware that we will definitely ask that pesky question, please go ahead and provide it to us when reporting the problem.
What we usually request:
- Server Operating System (OS) version and Service Pack (SP); full RDBMS version including Patches or Fixpacks (e.g. Oracle 10.2.0.3, DB2 V9 Fixpack 4a); ArcGIS Server (which includes ArcSDE) version, SP and Patches.
- Client OS version and SP; ArcGIS version and SP and Patches.
How to find your ESRI software configuration
Don’t know your ESRI software configuration information? Find out by running our Service Pack or Patch Finder also available at the Service Packs and Patches gateway: ESRI Service Packs and Patches Gateway.
Thanks for assisting us in determining the specific configuration in which you are experiencing problems.
- Cheryl C., Senior Support Technical Lead, Geodata Unit, ESRI Support Services