Sunday, September 11, 2005
"Windows is Shutting Down..."
This particular VPC was one provided by Microsoft, and included Windows Server 2003, Sharepoint Services, Sharepoint Portal Server, Exchange, Active Directory, the kitchen sink, etc. [grin].
Well, it turns out Exchange was the culprit. The first few times I attempted to shut down the VM, I got impatient and just forced it closed. When I finally waited, it shut down on its own. It took 10-15 minutes, but it DID shut down cleanly.
Patience is a virtue...
Friday, September 09, 2005
This is a bit embarrassing, but here's the background. About a year ago, I decided that I wanted to streamline as much of the TONS and TONS of paper in my office as I could. Between the magazines, receipts, printed documents, web articles, notes on projects and the like, I was drowning. And that doesn’t even begin to address the 1-2 filing cabinets I have with client files, financial info, etc.
So, about a year ago, after 2-3 weeks of thorough research, I sheepishly plunked down nearly $700 for this little dude. The embarrassment over this purchase has a couple of angles: I have a small business, and $700 is no small sum of money; and after I bought it, would you believe it - I left it under a table for nearly 12 months!?!?
Well, a couple of weeks ago, I decided to see how big a goofball I really was (no wisecracks, Dennis). I broke everything out of the box, hooked it up (USB 2.0) and installed the software. Within 10 minutes it was done.
Well, it quickly became apparent that this was NOT a purchase destined for eBay. I took a couple of 40-50 page documents, dropped them in, fired up the Canon scanning software, and had a handy Adobe Acrobat PDF file on my desktop for each one in about 3 minutes. WOW.
Since then, I have been slowly clearing my work area of all sorts of clutter and stuff I couldn’t bear to throw away, primarily from concerns that I might need it eventually. Did I mention that it does Optical Character Recognition (OCR)? Yep, every PDF file has the contents of the document contained within it, so they are all fully searchable, even from outside the document. Now, bear in mind that this works very well with scanned documents – for handwritten notes, etc. you’re on your own.
From a collaboration perspective, this will dramatically affect the way I and my team store and use information. We have all of of our files stored in Groove Workspaces, and Groove is installed on all our PCs. With client files, notes, etc. scanned and stored as PDF files, I can retrieve most anything I need wherever I am – and I’m out of the office a lot.
I still am a bit embarrassed that I spent $700 for something like this. But I sure like the way my office is shaping up.
I have been using Groove Virtual Office for several years. I couldn’t imagine my professional life without it. Recently, while working on a project, we had the need to share within our group a very large Microsoft Excel spreadsheet/workbook. This thing was big - 3+ MB in size!We began to see issues in terms of the spreadsheet becoming corrupted periodically, as well as LOTS of instances where there were duplicate copies of the spreadsheet from when more than one person had changed it within a certain timeframe. When I started crawling the Groove Support Forums, it quickly became apparent that I was not alone. There were tons of people having similar issues with Excel.
Excel is a special animal in the Office family. Within Office, it has the ability to handle multiple people accessing a particular spreadsheet all by itself. Part of it’s feature set (right out of the box) includes functionality that handles this sort of quasi-multiuser capability. Unfortunately, Groove expects the stuff he manages within a Groove Workspace to be quite dumb. It confuses him and causes the kinds of things we are seeing in the current version of Groove when Excel tries to handle the multi-user stuff.
In the support forums, they acknowledge this in multiple places. (I have to believe the recent acquisition of Groove Networks by Microsoft will rectify this situation – hopefully sooner rather than later. [grin] ) For now, there’s a LOT of consensus in the forums about a third party product you can purchase now that will do the trick.
An Indian firm has built an addon to Groove that resolves these issues now – and it’s reasonably priced ($120). GXcel - version 2.0 is a newly released version of a great tool that solves this sticky problem.
After many hours of questioning, debugging, and Googling the issue to death, we got on the phone with Microsoft. It turns out that the Sharepoint server in question had an underscore "_" in the Windows 2003 server name, something like "sharepoint_test". According to Microsoft, that's a known issue. Luckily for us, the server didn't have something on it which depended on the server name, like SQL Server. (I know it's possible to change it, but hey, it's a royal pain in the neck!) Once we changed the server name, all was good again.
Let's be careful out there!
Thursday, September 08, 2005
I recently spent more time than I’d like to admit trying to code sign an InfoPath form I was trying to publish. We had recently finished up an intranet project based on Sharepoint Services, and the client asked us to create a simple department level timesheet application that they could begin to use to record time & effort spent on project work. This form would allow two different views of the data: 1) Data Entry view and 2) Summary view.
In the data entry view, department employees would be able to maintain their timesheets during the week. At the end of the month, all the weekly timesheets in the department would be merged by the department secretary, massaged a bit, and then exported to an MS Word document that would be rolled up into a report that was presented to the corporate management team.
This last requirement was the kicker. The form would be deployed to a Windows Sharepoint form library – deploy it once to one location and everyone could access it centrally. Clean, quick, easy. However, when the department secretary used InfoPath to export the summary information for the month, InfoPath would actually invoke MS Word in order to transfer that data to it. That method invocation, in InfoPath terminology, requires the highest security level in InfoPath, level 3. As a result, the only way to allow the user to even use the form is to either 1) install it locally on his/her PC, or 2) code sign the form prior to publishing it on the Intranet or network share. Installing the form locally on each PC that needed it would defeat the bggest benefit we got from using Sharepoint. So, we had to code sign the form.
Well, after much weeping and gnashing of teeth, I finally figured out how to get that done. There’s a lot of information on code signing InfoPath forms; however, most InfoPath forms are still developed with script as opposed to managed languages like vb or c#. In my opinion, managed code has yet to gain a foothold all but a handful of shops. As a result, a lot of misinformation persists.
I assume you are using the following:
- Visual Studio.NET 2003
- InfoPath SP-1
Step 1: Get a code signing certificate
Most of the examples I read when searching for answers to this issue mentioned the process you had to go through to generate your own test certificate – that usually won’t wash when it comes to deploying in your organization. Typically, you have two choices: 1) Use the Certificate Server application built into Windows Server, or 2) Buy a real code signing certificate from a Certificate Authority (CA), like Verisign (verisign.com) or Thawte (thawte.com) (same company).
Verisign charges $399/year; Thawte charges $199/year. There’s no functional difference between the two – go with Thawte.
When you go through the registration process to purchase the certificate, you will be asked to create a password for your certificate – save this password. It’s very important that you store this in a safe place.
You will receive two files from the CA:
- a private key file that you will name something similar to “MyKey.pvk”
- a certificate file that you will name something like “MyCertificate.spc”
Step 2: Import/Export the certificate
Double click the certificate file to bring up the Windows Certificate store and import the certificate.
Now, you will need to export the certificate in a format necessary for code signing. Run the Certificate Export Wizard:
- Right click on your company name within the personal tab of the certificate store
- Click Export
- Within the Export Wizard, click Next and then choose the “DER encoded binary X.509 (.CER) format”.
- Give the cert a file name (i.e. “MyCertificate.cer”) and finish the wizard.
Note: DO NOT choose the “Base-64 encoded X.509 (.CER) format” in step 3 above – this was one of my problems initially when I tried to sign my code – wrong cert type.Step
3: Install and use the PVK Digital Certificate Files Importer
According to the MS website: “This download lets you sign Microsoft Visual Basic for Applications code in your Microsoft Office 2000 programs when using an authenticated digital certificate.” It also lets you sign an InfoPath form as well. Here’s where you can get the utility:
Once you download and run the install, it places the Import utility into the Windows directory. Open a CMD prompt, and execute the following command to load the digital certificate and its respective key into the local system store:
C:\>pvkimprt c:\mycertificate.spc c:\mykey.pvk
Note: Your paths to the above files may be different.
Step 4: Setup your form code project to use your new certificate
Copy the .cer and .pvk file into the formcode area of your InfoPath managed code project. In a typical InfoPath project in VS.NET 2003, you will have a project named something like “Project1”, and the formcode will be in a subdirectory in the project called “Project1formcode”. The “Project1formcode” subdirectory is where these two files need to be placed.
If you don’t already have it installed on your PC, grab a copy of the Microsoft Office InfoPath 2003 SDK. Once it’s installed there are two macros that you’ll need. Check this directory:
C:\Program Files\Microsoft Office 2003 Developer Resources\Microsoft Office InfoPath 2003 SDK\Macros
You should see a files called "InfoPathSDK.vsmacros".
Open up VS.NET 2003 and open that file to install the macros in Visual Studio.
If you check out the Macro Explorer, you’ll see two macros under InfoPathSDK:
- IPFullTrust – this sets the trust level of the code to full trust
- SignCode – this code signs the managed code (.dll) behind the InfoPath form.
Note: Ensure within the SignCode macro that the certificate file name (i.e. “MyCertificate.cer”) and the private key file name (i.e. “MyKey.pvk”) match up with the filenames in that macro. If necessary, edit the macro to ensure the file names match up.
Step 5: Sign both the InfoPath form and the managed code behind .dll
This is critical. What we did in the last step was to set things up in the InfoPath managed code project within Visual Studio such that when any compilation takes place, the managed code behind the InfoPath form is automatically forced to a state of full trust and the .dll is code signed.
In this step, we will do the same thing with the InfoPath form itself. Even though it has no script behind it, the form itself is required to be set to full trust and code signed in order for it to be able to make level 3 DOM calls like we need when we invoke MS Word.
So, with Visual Studio open:
- Right click on the form project and click “Open InfoPath”. This dynamically extracts the formfrom the .xsn file and loads it into InfoPath.
- Click Tools | Form Options | Security
- Under the form signing section, check the “Sign this form” checkbox, and then select your certificate
- Click OK
NOTE: Don’t expect to be able to save here! This is an extracted form file we are dealing with, so there’s nothing to save – you are signing the form and publishing it in one step. You’ll need to do this every time you publish the form.
Click File | Publish. This will force a fresh compile of the managed code .dll, code sign it, repackage the .xsn file, and prepare it to be published to Sharepoint.
Follow the InfoPath Publish Wizard to publish the form to an existing Sharepoint form library, a new form library or a file share.
That’s all there is to it. It’s not rocket science, but as I struggled to get this accomplished for my client, it became apparent that there was a
Please let me know if any of this doesn’t make sense. Good luck!