While reselling and supporting Post Master for Dynamics GP, I've worked with hundreds of customers who have reviewed, installed, tested, and implemented Post Master.
Most customers or partners do everything themselves without requiring any assistance, while a few need some assistance with the configuration and testing.
Then there are some that have an issue and need actual support. But by support, I don't just mean Post Master support. That would be easy.
Over the course of the last 6 years supporting Post Master, I've seen some of the strangest issues, many of which had nothing to do with Post Master, yet I've had to help the customer resolve them so that they could use Post Master in their environment.
For example, this is one of my favorites:
A transport-level error has occurred when receiving results from the server. (provider: TCP Provider, error: 0 - The semaphore timeout period has expired.)
I've had a handful of customers with this issue--for some reason there is a TCP/IP network error when Post Master attempts to query SQL Server. If you Google the error, you'll see lots of people have this issue under many different circumstances. It is a low level network error being returned by Windows or SQL Server, and there is very little I can do to fix it directly. It could be a network driver, NIC card, switch issue, or maybe even a wiring issue. But because Post Master happens to be the application that detects and logs the error, the customer expects me to be able to resolve it.
Another very common challenge is setting up SMTP so that Post Master can email posting reports or error notifications. SMTP poses many challenges, but the most common is that most non-IT folks don't understand SMTP (and even some technical folks don't understand it). With a name like "SMTP" this isn't surprising. SMTP Server, Port, and SSL / TLS are somewhat technical values that a typical end user wouldn't know about. And then you have SMTP relaying, which adds another layer of complexity. And then there is relaying to internal vs. external email addresses.
A customer just contacted me, saying that emails to internal addresses are delivered fine, but emails to external addresses generate an error. Looking at the Post Master logs, I found this explanation:
The server response was: 5.7.1 Unable to relay
The customer's SMTP server only allows relaying to internal addresses, so I asked the user to speak with their IT team to determine the best approach for relaying messages to an external address. Unless you've administered an Exchange or SMTP server (which fortunately I have), these concepts aren't obvious.
Then there is SQL Server security. Post Master has some custom SQL tables and stored procedures and a custom database role to manage access to those objects, independent of DYNGRP. We have had a few customers with very strict SQL Server security auditing that automatically deletes all SQL objects that are not on an approved list. No joke. Or manual audits that resulted in security roles and permissions being deleted. So we've had to figure out why Post Master's SQL security or objects have disappeared, and then figured out that it was a security audit that caused the problem, and request reviews and exemptions from the audit team.
We had one government client that was having a FIPS compliance audit who needed us to modify the internal Post Master encryption to allow them to pass their audit. Fortunately, I know what FIPS is, I understand encryption algorithms, and knew exactly how to modify Post Master to meet their requirements. And I just happened to know the history of and the difference between Rijndael and AES, so I was able to figure out why the rarely used and negligently undocumented Microsoft Windows FIPS compliance feature was complaining about Post Master's encryption. That's an entire world of technology that represents about 1% of Post Master functionality, but unless you fully understand it, you can't properly support it.
Then there is the very broad category of compatibility. First, there is Windows. I have found that User Account Control (UAC) produces such strange and inconsistent behaviors that I never know when it is causing the issue. When something odd happens, I ask the customer to try using Run As Administrator to see if that helps.
And don't forget good old Binary Sort Order in SQL Server. During one Post Master release, we accidentally had a SQL script that referenced a lower case table name, and a customer with Binary sort received an error.
We have come across other Dynamics GP ISV solutions that result in a mix of .NET 2 and .NET 4.x, requiring us to handle .NET compatibility issues in configuration files and at run time. And then there are direct product incompatibilities, where an ISV solution will cause errors with Post Master, or prevent a GP batch from posting properly.
Then there are the overzealous consultants. I maintain the Post Master user manual, which is now 41 pages in total. It has grown over time as I have documented additional troubleshooting tools and techniques, compatibility issues, you name it. I have even created an installation video and a configuration video, both of which provide step by step instructions. But occasionally there is an eager user, often a consultant, who glosses over the manual and attempts to use their own brand of kung fu to resolve errors. They will find a configuration file and edit it, despite the fact that nowhere in the user manual does it mention editing configuration files. They will start modifying SQL Server security. They will do things that I would have never anticipated, turning a 30 second resolution into a 15 minute support call.
So when it comes to supporting a software product, you need to know a whole lot more than just your product, and in many cases, you need to know them intricately--as in you need to be an expert.
This simple list doesn't begin to convey the depth of knowledge required, but I think it's a list of categories that serve as a starting point of what I need to know to support Post Master:
Networking
Windows
SQL Server
SMTP
.NET
Dynamics GP
Other ISV solutions
Other products will likely need to have other ancillary areas of expertise, such as data sources, peripheral hardware such as bar code scanners, external web services, you name it.
I suppose the same thing applies to Dynamics GP consulting. Customers expect you to solve any problem even remotely related to Dynamics GP, and those issues can have virtually nothing to do with Dynamics GP, other than the fact that they are causing a GP error. But one difference with supporting your own product is that you don't typically bill by the hour for that support--so you really need to have the knowledge to resolve issues quickly, even those that aren't directly related to your product.
Break out your WireShark network packet capture tool and get to work!
Steve Endow is a Microsoft MVP for Dynamics GP and a Dynamics
GP Certified IT Professional in Los Angeles. He is the owner of Precipio
Services, which provides Dynamics GP integrations, customizations, and
automation solutions.
No comments:
Post a Comment