In talking to my friend J.C. Hornbeck, who is the Blog Master of the SoftGrid Team blog, he suggested that I start a series of posts about the mistakes that new SoftGrid Admins make. In my 3 years with Softricity I was in charge of Training and Certification. I had the distinct privilege of teaching the SoftGrid class to almost every customer we had in the United States as well as people around the world. In that time I saw many people from differing backgrounds and skill sets make the same mistakes over and over again. No matter how much we emphasized it in class, the missteps still occurred.
The best part of my experiences in the past is that a lot of the missteps that people used to make “back in the day” were incorporated into later releases of SoftGrid. Progress is always being made to make it a better user experience.
I have broken these common missteps into 3 basic categories: The Client, The Server (including the management console), and lastly the Sequencer.
One of the most common missteps with the SoftGrid client that I have seen over the years is something that is actually merely overlooked. During the installation of the SoftGrid client, the installer program actually asks the user to configure their Desktop Configuration Server. The default behavior of this screen is to be deselected and therefore grayed out. Often, first timers will miss this step and then will not remember or know that they should go into the Client Management Console and add at least one server later.
Later on when they logon to the system, after having Sequenced applications and installed and configured the Server, they expect to see shortcuts for their SoftGrid applications on their desktop. Imagine the disappointment when they see nothing change. The first instinct is to start troubleshooting from the Server Management Console or even dive into the Sequence itself.
What I recommend people do when they do not see their applications appear at the anticipated shortcut locations is to reduce the areas of concern. What I mean by that is first see from the client whether they can go to “Start -> Run” and then enter the UNC of the SGVAS and successfully connect to the Content share. This tells me if they can even get to the share. If not they need to correct that issue. If this is the problem then begin by investigating IP addresses, names and typos, routing issues and of course DNS entries.
Next, within the Content share, navigate to the .OSD of the SoftGrid Package in question. Double click on that .OSD file. If the application launches by doing this then chances are we have a publishing problem and we would start troubleshooting at the SoftGrid Management Console.
Another popular mistake with these same results is that the .OSD file does not include the client’s operating system in the <OS VALUE> tags. This will prevent it from appearing as a shortcut BUT will still allow it to launch when manually double clicking the OSD file.
Now, another common cause of this issue with the same results actually is found in the SoftGrid Management Console. We will look at that soon.
Back in my day: Back in my day, when SoftGrid was version 3.2 and before, the SoftGrid client install didn’t even prompt you to configure the Desktop Configuration Server. You had to know that after the install you had to go into the control panel applet and manually enter it every time. Proof of progress is that it now prompts you for that information during install. More proof of listening to the customer is the fact that you can remotely enter that for a client in the Client Management Console (MMC) or even have it added with an unattended installation.
Another common “forget me not” is to reboot the client machine after installation. Because the SoftGrid installer did not prompt for a reboot after it completed I would estimate that 40% of people did not reboot the machine. What is more interesting is that 60% of the people would reboot even without a prompt. The Q:\ drive does not actually get set until this reboot occurs.
Most of the configuration or administration missteps occur within the SoftGrid Management Console. In classes we often planted mistakes inside of the .OSD files to intentionally make the students troubleshoot SoftGrid from day 1. A good majority of the students however seemed to find themselves in trouble by their own hand.
Without a doubt, I think the most common mistake happens when the person is publishing the application records. In the wizard, the “Import Application” record prompts the user for the location of two critical files, the .OSD and the .ICO. Many people will inadvertently walk the directory structure of the server to locate these two files. That would not be an issue if they walked via Network Neighborhood. Instead, they walk the local C:\ drive down to Program Files\Softricity\SoftGrid Server\Content. By doing it this way they have set the path to the .ICO and .OSD as a local directory relative to C:\. It is important to know here that when the client communicates with the server the client is requesting the location of the .ICO and .OSD files so that the client can then go an retrieve them to their local. If these paths are set to look in the C:\ drive, even though at the server that will resolve correctly, the client will actually look in their local C:\Program Files\Softricity\SoftGrid Server\Content. This does not exist on the client, ergo no shortcuts.
In order to avoid this behavior you should always use the network when browsing to the .ICO and .OSD files. This way they will come into the application record as a UNC path instead. It is also a good idea to set the “Default Content Path” on the root’s properties in the SGMC. It is true that the paths could be set to a HTTP path instead. The point is, they should not be set to a local path but instead, UNC or HTTP only.
Another common mistake I see people do occurs when they try to launch the management console. When you launch the management console and make a connection to a SoftGrid system it prompts you to connect to the management web server. People will often mistake this as a prompt for the SoftGrid VAS instead. What is happening here is that the MMC is actually connecting to the SoftGrid Management Web Service. This is the piece that was installed on a box running IIS 5.0 or greater. It is this management web service that is actually making the connection to the SQL Data Store. People see a prompt asking for a name and automatically assume it is the SoftGrid VAS. This will work if the VAS is installed on the same box as the Management Web Service. But if the pieces are distributed in the production environment an error will be returned.
I am afraid the only way to avoid this is to keep the names of your servers straight. I know this sounds glib but truly this mistake is purely naming. The other issue that is related to this step is the logon name. People will often be logged onto the system as an account, let’s say Admin. When they try to access the MMC it will use the current credentials by default. If the Admin account in this case is not part of the SoftGrid Administrators group then the connection will fail. People will often have an account named “SGAdmin” which is the member of the SoftGrid Administrators group. Again, the way to avoid it is with keeping the names straight.
One more common misstep is to install the SoftGrid Server and then NOT immediately share the \Content directory. Sorry, “folder” for all those who don’t remember Windows 3.1. What generally happens here is that they will do the install perfectly. It will ask them for the path to their \Content directory and they will accept the default location of C:\Program Files\Softricity\SoftGrid Server\Content. They then continue the install without any issues. Then they will move onto the Sequencer, sequence an application or two and move the packages over to the SGVAS’ C:\Program Files\Softricity\SoftGrid Server\Content directory. Then they will setup the SoftGrid Client and point it to the SoftGrid VAS as their DCC. Then all of their hopes and dreams are dashed when nothing appears on the client.
The bigger problem for this person is that so much time has passed and so many other things have been done since the VAS’ install that they simply have forgotten about the \Content directory actually needing to be shared. Now, the first sign that there is a problem is when the client tries to hit the UNC of the \Content share with “Start -> Run” and it fails.
Another glib answer I’m afraid, but it is probably obvious to you that the directory needs to be shared. This should be done as soon as the VAS install is completed. If during sequencing you actually map a drive to the VAS \Content share to move your package’s folder to, it would have been obvious even sooner.
Aha, I knew there was one more common misstep I wanted to point out in the MMC. When you import a suite of applications, the default behavior in the MMC is the check box that reads “Enabled” is not selected. This box appears on the first screen of the Import Wizard and is subtle in its location as it appears on the right side about half way up the dialog box. It is very easy to miss and can be one of the more frustrating misses you can make.
Take it from me. I was demonstrating SoftGrid during a presentation at a large event. I was in a movie theatre, the bright lights were shining on me, blinding me to the hundreds of people sitting in the amphitheater style seating staring at my every move. My microphone was amplifying my already booming voice such that my every breath was being heard by the enraptured audience. I confidently imported Office 2003 by browsing to the .SPRJ file, it in turn read the names of the .OSD file and started the creation of the application records for all the applications in Office 2003. I moved with ease through the steps of the wizard explaining in detail each step along the way to my impending failure. I switched over to my client and told them to watch in amazement for the sudden appearance of icons. And then, nothing happened. No icons. No apps. Nothing!
And to make matters worse one of the audience participants moved to a microphone stand setup in the aisle of the theatre and pointed out to everyone that I had not selected the “Enabled” check box. I turned bright red and of course told everyone I had done it on purpose to show this often made rookie mistake.
This behavior only happens when you import a suite of two or more applications in the MMC. If the SoftGrid package only includes one application then the default behavior is to have the “Enabled” check box selected by default. Also, when you import a suite of applications, the .ICO and .OSD paths will be grayed out or unavailable. This is because the value for each application in the suite is different, therefore the boxes will appear gray.
In short, if the path boxes are gray you should immediately look at the “Enabled” box and it will be clear. In this case it needs to become a reflexive action like seeing a yellow light and speeding up.
Now of course I need to point out how far we have come in this case from the earlier days. Back in the days of SoftGrid 3.2 and before, when you wanted to import a suite of applications, say Office 2003, you had to do it manually. I know, it is my most dreaded word also, “manual”. What we used to have to do is import the Word .OSD file and take all the steps in that wizard. Then when that was finished, we had to repeat those same steps for the Excel, Access, PowerPoint, etc. .OSD files. Each one individually. You kids today have it easy by importing a single .SPRJ file and being done with it.
Next up, the Sequencer’s missteps.
- Sean Donahue
http://blogs.technet.com/softgrid/archive/2007/08/29/common-softgrid-rookie-mistakes.aspx On the SoftGrid
Sean Donahue over at the SoftGrid Team Blog authors a brilliant piece on common mistakes that rookie administrators make when first implementing and administering SoftGrid. He writes: The best part of my experiences in the past is that a lot of the missteps