Convergence 2011 – IT Professional Class Offerings
CSGP06-R1 Getting More Out of Microsoft Dynamics GP: 50 Tips in 50 Minutes
Track: Microsoft Dynamics GP
Speaker(s): Mark Polino
Room: Marcus Auditorium
Audience: IT Professional, Technical Decision Maker, Business Decision Maker, Power User, End User
Skill Level: 100 - Introductory
Industry:
Tuesday, April 12
15:00-16:00
Add to Calendar
Session Details
Back by popular demand, this fast-paced workshop delivers something for everyone--beginners, intermediate and advanced users--as we share Microsoft Dynamics GP tips that you'll want to race back and implement. With a briefcase of little nuggets that 'wow', including the how-to's of the custom links feature, deleting auto complete entries and adding comments without using a comment ID, you don't want to miss this. Past attendees have shared that this was the most useful session of the conference.
CSGP07-R1 SQL Reporting Services Using Microsoft SQL Server 2008
Track: Microsoft Dynamics GP
Speaker(s): Jen Olson
Room: A410
Audience: Prospect, Technical Decision Maker, End User, IT Professional, Business Decision Maker, Power User
Skill Level: 200 - Intermediate
Industry:
Tuesday, April 12
15:00-16:00
Add to Calendar
Session Details
Attend this session and you'll soon see the flexibility at your fingertips when you discover how to use Microsoft SQL Reporting Services 2008 and the Report Builder 2.0 tool to create reports and gauges with your Microsoft Dynamics GP data. See how the reports you have created can be deployed and integrated with your Microsoft Dynamics GP client and rendered within your report manager web page.
CSGP08-R1 Connect & Collaborate with Business Portal
Track: Microsoft Dynamics GP
Speaker(s): Tom Higginbotham, John Dooley
Room: A305
Audience: Technical Decision Maker, IT Professional, Business Decision Maker, Power User
Skill Level: 200 - Intermediate
Industry:
Tuesday, April 12
9:00-10:00
Add to Calendar
Session Details
Join us as we showcase how to leverage the Microsoft SharePoint platform to extend the reach of Microsoft Dynamics GP in your organization and enhance the capabilities of Business Portal. Explore tools that are available--many which do not require deep programming knowledge or large dollar investment--and investigate how you can take advantage of them to build collaborative solutions. You'll see scenarios that show how to harness the power of the platform as well as how to make your people more productive.
CSGP09-R1 Installing & Troubleshooting Business Portal 5.1
Track: Microsoft Dynamics GP
Speaker(s): Jerad Plesuk
Room: A313/314
Audience: Technical Decision Maker, IT Professional
Skill Level: 200 - Intermediate
Industry:
Tuesday, April 12
10:30-11:30
Add to Calendar
Session Details
Business Portal 5.1 for Microsoft Dynamics GP 2010 is the newest version of Business Portal, and the first designed to utilize all the advantages that a 64-bit environment has to offer. Learn the best practices, tips, and hints for installing
Wednesday, February 23, 2011
Wednesday, February 16, 2011
ACE Microsoft Dynamics GP SQL Installation and Configuration Audit
Microsoft Dynamics GP runs on the Microsoft SQL Server database which is a scalable platform that can run a high transaction volume with little support. SQL enables you to do query, search, synchronize, report, and analyze your data easily and effectively.
Having your business data in SQL Server ensures that you have the latest advances in data integrity, performance, and manageability. You can take advantage of SQL Reporting Services to create Web-enabled reports, use integration tools like ACE eConnect templates to communicate seamlessly with other database applications, and restore your company database to a specific point in time with SQL Server’s backup and restore functionality.
However, even Microsoft SQL is not maintenance-free. Here are some common items ACE can recommend or assist you with in maintaining a stable and well performing Dynamics GP system.
Schedule regular database maintenance. As databases grow, it is important to allow SQL to re-tune the database for optimal performance. All the tools you need to do this are part of a SQL database maintenance plan. How often it needs to run depends on your environment, but generally weekly maintenance runs are sufficient. Be sure your maintenance plan includes tasks to check integrity, rebuild indexes, reorganize indexes, and update statistics.
Determine your server performance baseline. Shortages in memory, disk, or CPU can all cause major performance problems. Windows Server comes with everything you need to monitor a server out of the box. Check out Windows Performance Monitor and its scheduling capabilities to get a clear view of what’s happening on your server. Often times major bottlenecks can be simply rectified, such as dropping in some additional memory in a RAM starved server.
Select the right RAID level for the job. RAID comes in many flavors and each has its strengths and weaknesses. Raid 5 is popular because it is usually the most economical since you lose only one drive worth of space in your array for the parity data. However, it usually has the slowest write performance of just about any type of RAID. Selecting RAID levels with good write performance like RAID 1 and RAID 10 can provide better performance. Avoid RAID 0 as it does not provide any fault tolerance.
Understand the difference between simple and full recovery model in SQL. SQL writes all changes to the database to the transaction log. In simple recovery mode, this transaction log is automatically truncated periodically. In full recovery, it is your responsibility to manually truncate the transaction log, usually by performing a transaction log backup. The benefit of full recovery mode is that you can restore to an individual point in time, not just to the time you perform a full backup. If you have problems with your transaction log growing constantly, and you are not concerned with point in time recovery, choose simple recovery mode.
Do not locate transaction logs and database files on the same physical drive. Many know you should place database and log files on separate drives. The science behind this is that SQL must write to both files at the same time when transactions are applied to the database. Putting the files on separate physical disks allows these activities to happen in parallel. And consider that a single physical drive or array partitioned as two drives may not provide the security of two separate drives.
Use correct auto-growth and auto-shrink settings. It’s important to understand that SQL files can be logically and physically fragmented. Frequent shrink and growth commands executed on the database will cause fragmentation of the database files. It is better to set the size of the files to a reasonable size right away, thereby reserving a contiguous area of disk platter. This way, the logical amount of data inside the files can grow and shrink without having to alter the physical size of the database.
Don’t assume a flat file backup is sufficient for recovery purposes. The maintenance plan wizard in SQL management studio may be sufficient for many applications, but it may not provide the same type of comprehensive reporting and monitoring you would get from a centralized backup with a commercial utility. To back up a SQL database properly, you should strongly consider using commercial backup utility which is SQL aware. At a minimum, both an on-site and off-site backup strategy should be implemented.
Properly back up the transaction log. Fortunately, a full backup will not to truncate the transaction log. This is one of the most misunderstood aspects of using SQL, even among database administrators. SQL does not truncate the transaction log when performing a full backup. Doing so would break your transaction log chain and remove your ability to do point in time restore, which is a central point of the full recovery model. If you are unsure, just switch to simple mode and take full backups. This way SQL will manage the transaction log automatically.
Microsoft SQL Server does have the ability to recover from problems. Built into the application are several data recovery and data protection mechanisms designed to protect your business data in the event of hard drive or server failure. SQL Server stores all information and changes in the transaction log, which allows you to backup and restore it to any point in time, not just the time you last took a backup.
Microsoft SQL provides a powerful, yet flexible framework to store and access your business data. Unfortunately many companies purchase the software, install it and never look at the server again until it runs out of space or they realize that they need to restore to a backup and there isn't one because the backup plan is no longer running.
Protect your investment.
ACE can assist with one-time or ongoing preventative maintenance of your SQL Server. Initially, we will complete a Microsoft Dynamics GP SQL Installation and Configuration Audit where you will come away with a comprehensive document of your current installation and configuration as well as recommendations to become complaint with Microsoft recommendations. From there we can set up a schedule that makes sense for your organization to review your server and complete preventative maintenance procedures to protect against data corruption and ensure that backups are running properly and are reliable. Take the first step toward protecting and maintaining your software investment today and engage with us for an audit of your GP and SQL Installation.
Having your business data in SQL Server ensures that you have the latest advances in data integrity, performance, and manageability. You can take advantage of SQL Reporting Services to create Web-enabled reports, use integration tools like ACE eConnect templates to communicate seamlessly with other database applications, and restore your company database to a specific point in time with SQL Server’s backup and restore functionality.
However, even Microsoft SQL is not maintenance-free. Here are some common items ACE can recommend or assist you with in maintaining a stable and well performing Dynamics GP system.
Schedule regular database maintenance. As databases grow, it is important to allow SQL to re-tune the database for optimal performance. All the tools you need to do this are part of a SQL database maintenance plan. How often it needs to run depends on your environment, but generally weekly maintenance runs are sufficient. Be sure your maintenance plan includes tasks to check integrity, rebuild indexes, reorganize indexes, and update statistics.
Determine your server performance baseline. Shortages in memory, disk, or CPU can all cause major performance problems. Windows Server comes with everything you need to monitor a server out of the box. Check out Windows Performance Monitor and its scheduling capabilities to get a clear view of what’s happening on your server. Often times major bottlenecks can be simply rectified, such as dropping in some additional memory in a RAM starved server.
Select the right RAID level for the job. RAID comes in many flavors and each has its strengths and weaknesses. Raid 5 is popular because it is usually the most economical since you lose only one drive worth of space in your array for the parity data. However, it usually has the slowest write performance of just about any type of RAID. Selecting RAID levels with good write performance like RAID 1 and RAID 10 can provide better performance. Avoid RAID 0 as it does not provide any fault tolerance.
Understand the difference between simple and full recovery model in SQL. SQL writes all changes to the database to the transaction log. In simple recovery mode, this transaction log is automatically truncated periodically. In full recovery, it is your responsibility to manually truncate the transaction log, usually by performing a transaction log backup. The benefit of full recovery mode is that you can restore to an individual point in time, not just to the time you perform a full backup. If you have problems with your transaction log growing constantly, and you are not concerned with point in time recovery, choose simple recovery mode.
Do not locate transaction logs and database files on the same physical drive. Many know you should place database and log files on separate drives. The science behind this is that SQL must write to both files at the same time when transactions are applied to the database. Putting the files on separate physical disks allows these activities to happen in parallel. And consider that a single physical drive or array partitioned as two drives may not provide the security of two separate drives.
Use correct auto-growth and auto-shrink settings. It’s important to understand that SQL files can be logically and physically fragmented. Frequent shrink and growth commands executed on the database will cause fragmentation of the database files. It is better to set the size of the files to a reasonable size right away, thereby reserving a contiguous area of disk platter. This way, the logical amount of data inside the files can grow and shrink without having to alter the physical size of the database.
Don’t assume a flat file backup is sufficient for recovery purposes. The maintenance plan wizard in SQL management studio may be sufficient for many applications, but it may not provide the same type of comprehensive reporting and monitoring you would get from a centralized backup with a commercial utility. To back up a SQL database properly, you should strongly consider using commercial backup utility which is SQL aware. At a minimum, both an on-site and off-site backup strategy should be implemented.
Properly back up the transaction log. Fortunately, a full backup will not to truncate the transaction log. This is one of the most misunderstood aspects of using SQL, even among database administrators. SQL does not truncate the transaction log when performing a full backup. Doing so would break your transaction log chain and remove your ability to do point in time restore, which is a central point of the full recovery model. If you are unsure, just switch to simple mode and take full backups. This way SQL will manage the transaction log automatically.
Microsoft SQL Server does have the ability to recover from problems. Built into the application are several data recovery and data protection mechanisms designed to protect your business data in the event of hard drive or server failure. SQL Server stores all information and changes in the transaction log, which allows you to backup and restore it to any point in time, not just the time you last took a backup.
Microsoft SQL provides a powerful, yet flexible framework to store and access your business data. Unfortunately many companies purchase the software, install it and never look at the server again until it runs out of space or they realize that they need to restore to a backup and there isn't one because the backup plan is no longer running.
Protect your investment.
ACE can assist with one-time or ongoing preventative maintenance of your SQL Server. Initially, we will complete a Microsoft Dynamics GP SQL Installation and Configuration Audit where you will come away with a comprehensive document of your current installation and configuration as well as recommendations to become complaint with Microsoft recommendations. From there we can set up a schedule that makes sense for your organization to review your server and complete preventative maintenance procedures to protect against data corruption and ensure that backups are running properly and are reliable. Take the first step toward protecting and maintaining your software investment today and engage with us for an audit of your GP and SQL Installation.
Subscribe to:
Posts (Atom)