The ArcGIS Server Administration Toolkit provides you the tools and scripts to help you administer your ArcGIS Server. These tools haven been written in Python and connect to the REST Admin of an ArcGIS Server allowing you to quickly and easily perform some common administrative functions, including: 

• Stopping, starting or deleting a service
• Renaming a service
• Modifying the log level and clearing old logs
• Upload and registering an SOE
• Creating a FeatureClass from the locations a map service was viewed at (by inspecting the logs)
• Publishing Service Definitions (.SD)

The tools inside this kit are presented in three main ways: Tools, Code, and standalone executable.

ArcGIS Server 10.1 Administration Toolkit Now Available

Demand is increasing for web-based applications that give your colleagues and the public the ability to obtain the results of geospatial analysis online.

You can provide these types of applications using geoprocessing services authored using ArcGIS for Desktop and published with ArcGIS for Server from Esri. 

During this seminar which will take place on Thursday, June 21, 2012, you will find out how to use the new ArcGIS 10.1 for Desktop and ArcGIS 10.1 for Server releases to author and publish geoprocessing services and use those services in web applications. 

There will be three offerings at: 9:00 am, 11:00 am, and 3:00 pm PDT (U.S. & Canada).

Live Training Seminar, How To Author And Publish Geoprocessing Services

The ArcGIS API for JavaScript 3.0 has been released! This comes on the back of the recent release of ArcGIS 10.1.This latest version adds many new features and enhancements that work against ArcGIS for Server 10.1 and ArcGIS Online.

View: What’s New

ArcGIS API For JavaScript 3.0 Released

I know many users are keen to upgrade and start using ArcGIS for Server 10.1 but there needs to be a plan in place before one migrates. As many of you are aware, AGS 10.1 has been redesigned and comes packed many new features that make our lives easier. These are all wonderful but users need to understand these changes. 

New installations are easy and simple where as migrations are complex and time consuming.

I migrated our production basemaps last night. These are on http://services.arcgisonline.co.nz. This was an AGS running 10.04 and had ~ 4 services. One might think that this would be reasonably straight forward with a simple uninstall of AGS 10.04 and install of AGS 10.1. 

~ 4.5 hours later I was still going. I was also conscious of downtime as this is a production server. No the services were not down for ~ 4.5 because I did this in parallel. They were down for ~ 10 minutes. 

Why did it take so long? Well it had to do with existing data, caches and services and reconfiguring this for AGS 10.1

So I strongly suggest that existing clients with larger or complex installations of AGS 10.1 spend time planning their migrations. It’s not as simple as going from AGS 9.3.1 to AGS 10.

Perhaps a health check from a BP or our Professional Services Team might be required to understand what the impact will be and due to a typical migration being time consuming I would recommend this be done in parallel. 

Here are a few technical aspects to take into consideration when thinking of migrating to AGS 10.1:

1. Make sure you thoroughly understand AGS 10.1. Conceptually it’s the same but technically very different.
2. Understand the environment you are working in. AGS 10.1 ties itself closely to the network and if DNS’s and domain names are not configured properly the site creation will fail.
3. Understand how the web adaptor works. This will be needed for those clients that are migrating so that backwards compatibility is maintained.
4. All existing services will need to be republished. MXD’s and MSD’s are no longer supported. Users will have to go back to the source data, open this up in AG Desktop 10.1, run through the sharing wizard and analyse the document. Correct any errors. The analyser is a lot more sensitivity at this latest release.
5. All existing data sources will need to be registered with AGS 10.1. You need to do this as part of the publishing process. 
6. If you are publishing existing cached map services, you need to make sure that their conf.xml files can be read by AGS 10.1. This might require manipulating the conf.xml to suit so understanding how the new caching system works in AGS 10.1 is equally as important.
7. There are many changes to the REST interface so familiarise yourself with where things are. Once existing services are published they are backwards compatible.
8. Determine whether users require HTTPS. This requires a whole separate set of configuration. It’s also harder if you are working with the web adaptor so make sure this is planned. Existing CA certifications cannot be easily imported into AGS 10.1 but you can used the self-signed certificates easily enough. You need to work out if these scenarios work for your environment.
9. There is a breaking change on the REST interface with the GeometryServer being moved to the utilities directory as opposed to the root so evaluate what impact this will have on other applications.
10. Plan the relevant permissions. The authentication models are AGS 10.1 have changed. If you are using tokens, make sure these are configured appropriately.  

Are you working to put together a migration plan for the transition to ArcGIS for Server 10.1? Because there are significant changes in the software architecture at ArcGIS for Server 10.1 a number of hints and tips have been put together to help you through the process.

Good to Know’s

• At ArcGIS Server 10.1, service configuration files from previous versions will no longer work. (At previous releases, service configuration files would remain valid.) Version 10.1 uses a different mechanism for map services called the Service Definition (SD), which is not a text configuration file as it was in previous versions. Previously created map caches will remain valid.
• ArcGIS Server 10.1 no longer uses SOM and SOC.  At 10.0, you had to manage accounts for each, but at 10.1, you’ll only have to manage one account.
• The concept of a distributed installation with multiple SOC machines attached to one or more SOM boxes is also going away. Each GIS server is its own installation. GIS server machines and services may be clustered together using tools available in ArcGIS Server Manager to offer better computing power, but each ArcGIS Server machine is effectively autonomous.
• There is no longer a differentiation between the Java and .Net versions of ArcGIS Server.  Now it’s just ArcGIS Server. The product installs with its own application server; this server should be dedicated to ArcGIS Server and nothing else. Esri has created applications, called “Web Adapters,” that link your current server of choice (IIS or a J2EE application server) to the GIS server instance. These applications are small broker components that basically forward requests from your web server to the internal server used with ArcGIS.
• When you create an administrative connection to ArcGIS Server 10.1, you’ll have the option to package and copy data in the Service Definition and push the whole package up to a GIS server. This means that an SD is portable – a user in one location can create a service definition and ship it to the GIS server owner without having to worry about an account having access to data in the remote location.