SQL Server Management

In my experience I have noticed that many different companies do not manage their database correctly, or even at all.  I have included a link to the Microsoft TechNet article describing strategies for managing your SQL database.  There are lots of helpful hints pertaining to log management, backup and restore procedures, rebuilding faulty system databases, importing and exporting data, and even copying databases from machine to machine.  This light reading will make you more aware of some possible issues and provide you with basic knowledge of recommended procedures to get the most out of your SQL Server.

http://technet.microsoft.com/en-us/library/ee210540%28v=sql.105%29.aspx

Andrew Skovran
Support Engineer
ImageSource, Inc.

To Image or Not to Image

Having chosen my career path towards project management, I am not as strong in desktop support as many others. However, I can work my way through just about anything but it might just take a little longer. I thought I would share my experience over the past week in attempting desktop support for myself.

Continue reading

Installation Hand Off to the Client

As an integrator there are many things we can do as far as making the install a success, but only a very limited amount we can do to guarantee its continuing success. One of the most often seen issues is the handoff of an installation to the client, in particular the maintenance of the database.

Continue reading

Implementing Content Management Systems with Multiple Environments

A common recommendation we have when designing Enterprise Content Management systems is the use of multiple environments.  I am referring the use of Development, Test, and/or QA environments to complement a Production environment.  There are many advantages to deploying systems with multiple environments, and I would like to discuss the role of multiple environments and the advantages to implementing them for your ECM system.

Depending on the size and complexity of the solution different supporting environments are recommended.  For, example with a smaller departmental level solution with little or no custom development, it is common to only recommend one supporting environment used for development and testing.  Now let’s take another example where a customer has an enterprise level ECM system with custom development and a requirement for minimal system downtime.  The following is a common layout for this type of system:

  • Development Environment – Used for custom development and preparation for testing changes to the ECM system.  This environment is usually much smaller than the Production Environment and is commonly running on virtual servers/machines.
  • Test Environment – Used for end to end testing of changes to the system.  Changes are certified in this environment prior to moving to the QA or Production.  This environment is usually smaller than Production, but it is imperative that the functionality is consistent to ensure proper testing and certification of the changes.
  • Quality Assurance Environment – This environment serves a couple of purposes and it closely mirrors the architecture of the Production Environment.  Performance load testing and client acceptance are performed in this environment.  In some instances, this environment can also serve as a disaster recovery environment in the event of a Production outage.
  • Production Environment – Used for the ECM Production System.

This environment configuration is representative of a common layout for multiple environments, but depending on the organization and solution it can vary.  The ECM solution architects play a valuable role in recommending the optimal configuration.  At ImageSource, we have extensive knowledge and experience with ECM architecture and take a great deal of pride in designing the correct layout for the customer and the solution.
Continue reading