Problem starting MGE 2009 Server Service

[jacklloyd]

After installing MGE 2009, I added a new user account and changed the location of the repositories (not enough room on the drive MGE got installed on). Now, when I try and start the server service I get this:

C:\Program Files\Autodesk\MapGuideEnterprise2009\Server\Bin>mgserver2009 /interactive
Running the server interactively as an application instead of as a service.

(2860) Failed to retrieve message for "MgConfigurationException".
Failed to retrieve message for "MgConfigurationPropertyValueIsInvalid".
Exception occurred in method MgServer.open at line 747 in file d:\buildforgeprojects\carrera_nightly\build_32.2\ent\os\server\src\core\Server.cpp

(2860) Server stopped.

I modified the serverconfig.ini file and put the repository locations back to the original install locations and I still get this error. I ran a repair on the server and web server extensions but still no luck. Can this be fixed somewhere else or do I need to reinstall?

Thanks - Jack

[Anonymous]

jlloyd wrote:
> I modified the serverconfig.ini file and put the repository locations back to the original install locations and I still get this error. I ran a repair on the server and web server extensions but still no luck. Can this be fixed somewhere else or do I need to reinstall?

Are you able to post the contents of the serverconfig.ini file
somewhere? I wonder if you deleted (moved) that file and ran a repair
install in the server if it would replace it.

J

[jacklloyd]

I ended up uninstalling and reinstalling to fix the problem. Then, dumb as it may sound I tried moving only a few of the repository locations and ran into the same problem. Maybe we're not allowed to move them? If we can't move them, why is there an option to do so in the server admin? I'll try your suggestion of deleting (moving) the serverconfig.ini file and running a repair. Stay tuned....

Jack

[jacklloyd]

Jason,

Renaming the serverconfig.ini file and running a repair on the "Server" did the trick. Great suggestion! Now, I just need to know if any of the repository folders of the "Resource Service" can be moved somewhere else. Thanks for your help with this.

Jack

[dswilson]

Yes the Repository\* folders can be moved to another drive. The server temp directory, Packages and log files can be moved. The paths for WMS, WFS, Resources and the Schema cannot be moved.

You should use notepad to edit the file if you can't change them from Site Admin.

Regards,
Dave

[jacklloyd]

Thanks Dave. Do you have any idea why I am having a problem doing this? I tried it from the Site Admin with no luck and also by editing the serverconfig.ini file in notepad. Do these directories have to pre-exist or will they be created automatically (I pre-created them). Are there any "special" permissions required on these directories? Is there a special order of events when trying to relocate these folders (i.e. create folders, change in site admin, restart MGE server, reboot etc). Any insight you can provide with this is appreciated.

Jack

[dswilson]

I generally copy the subdirectory structure of the Repository directories to a an alternate drive and replicate the full path including Program Files so that the only thing you have to change is the leading C in all the path references to the new drive letter either in Site Admin or when editing the file. You do have to do a service restart after saving all the changes before they take effect. Only a few of the subfolders under Repositories are created automatically, but rather than fight and learn which ones I just copy everything after a clean install.

Dave

[jacklloyd]

Sounds logical. I wasn't keeping the "program files" portion of the path but will try it. Have you successfully done this with GE 2009?

Now that I have you, can you give me some insight on the IDX files created by FDO Shape provider? Seems like every time I access a directory with Shape files, the IDX file get regenerated. This is a performance killer because our GIS library has over 500 Shape files. This is with GE and Map 2008.

Thanks - Jack

[Anonymous]

DSWilson wrote:
> I generally copy the subdirectory structure of the Repository directories
> to a an alternate drive and replicate the full path including Program
> Files [snip]

I chose to create something like E:\MapGuide and place them there so
that other admins know that it's data (not executables). I also added
an "Unmanaged" directory to this structure for storing SDF files that I
want to update outside of the Studio mechanism.

I like that MapGuide allows you to do this. Programs that force you to
store data in their install location really scare me 🙂

Jack, is it possible that the user you're running the MapGuide service
as doesn't have permissions to the alternate location that you're using
for the repositories?

Next time you do this, I'd suggest either commenting out the original
values, or saving a backup of the server config first 🙂

Jason

[jacklloyd]

Jason,

Good point. The MGE 2009 service is running under the system account, and it is possible that this account doesn't have permissions on that folder. I run my MG 6.5 service under a specially created account. Is it okay to do this with the 2009 service? I was afraid to change it.

You mention updating the SDFs outside of Studio. Are you using FME? I think the automation of SDF creation in Studio is really lacking. Even though the SDFLoader in 6.5 was DOS based, you could at least run it from batch files that could be regularly scheduled to run. This is one of my biggest concerns with 2009, how do I keep my data current. Do you still find SDFs to be better performers than Shape files?

I agree with you on the "unmanaged data option". It's a step in the right direction for me. It's not a black box like the built in repositories.

I might try relocating the repository folders again tomorrow. I was starting to build a map using the new templates. Glad to see this was added in 2009.

Thanks - Jack

[dswilson]

There is a Studio API that could be used to potentially create the SDF 3.0s via batch from a client machine. There are methods for the creating packages which is the process used in a load procedure. You can probably initiate the first steps which does the conversion from SHP or SDF 2.1's.

Dave

[Anonymous]

jlloyd wrote:
> Good point. The MGE 2009 service is running under the system account, and it is possible that this account doesn't have permissions on that folder. I run my MG 6.5 service under a specially created account. Is it okay to do this with the 2009 service? I was afraid to change it.

Yes, absolutely. In fact, you will need to do this if you want to
access files (such as images) stored on a network share.

> You mention updating the SDFs outside of Studio. Are you using FME?

Yes. FME does a decent job of creating SDFs; its only limitation being
that you can't select multiple geometry types.

> the automation of SDF creation in Studio is really lacking.

No comment 🙂 Apparently there's an API you can use to set up batch
translations that could run from the command line, but you need an
install of Studio for that and I think you have to compile code. Dave
(or maybe someone else) posted an example of how to do this in these
groups a while back.

> Do you still find SDFs to be better performers than Shape files?

Absolutely. To my understanding there are a few reasons for this. SDF
uses FGF (FDO Geometry Format, also know as Autodesk Geometry Format) to
store geometry, so you save a lot of cycles not having to translate each
geometry into a format MapGuide can use. All of the attribute data is
stored directly with the geometry, so you don't need to read three
(geometry, index, dbf) files just to get the attributes. Things like
spatial context and schema are stored directly in the file and only need
to be read rather than generated. Etc, etc... SDF is basically
MapGuide's (or more accurately FDO's) native format. Apart from
performance, I like them because I only need to deal with one file. You
could even store multiple feature classes per file (I've done this a
bit) but apparently this doesn't perform as well as one class per file.
I haven't actually tested this myself, but the developers say it is,
and their word is law 🙂

https://trac.osgeo.org/mapguide/ticket/265

> I was starting to build a map using the new templates. Glad to see this was added in 2009.

Yeah, me too. The reason we started working with DM Solutions initially
was that the built-in templates were not flexible enough for our needs.
I think it's great that DM and ADSK were able to work together to get
this into MapGuide natively. You can follow its development here if
you're interested:

http://trac.osgeo.org/fusion

Does Enterprise come with documentation for the flexible templates?
We've gone to using the open source version, but may end up going back
to Enterprise if we decide to implement Topobase.

Jason