April 2006 - Posts
Today a client asked me to set up an account for a soon to be new employee. Since this employee is to take the place of one who recently left the company, the easiest way was to rename the old account. Rename is a bit of an understatement, there are a lot of things in the account that need renaming. I've done this many times before, especially for this particular client, and it works well. However today, Mr. Murphy was there to foul things up. Seems when I tried to launch Outlook, it wouldn't connect. I've seen this before when the account needs to be reset in Outlook. I brought up the Outlook app in Control Panel to configure it. I entered the name of the new user and asked that it 'Check Name'. It did and everything seemed fine. Still, Outlook was not able to access the mailbox. I also checked with GoldMine which accesses Exchange mail via POP3. It failed with a user name/password issue as well. I checked the server and the workstation/Outlook configureation for everything I could think of. I won't bore you with all I tried, but eventually I decided to see what would happen if I logged in on another workstation. There I was able to bring up Outlook fine. 'Ah!', sez I. Must be a problem with the particular workstation, an old Windows 2000 Pro jobbie, but one that's been in constant use up until just recently. I stumbled upon an article via my good friend Mr. Google where someone said they happened to stumble upon the suggestion that uninstalling and reinstalling tcp/ip had fixed a similar issue for them. What the heck, I'll gave it a try. Lo' and behold, it worked! Suddenly Outlook started behaving. Also, GoldMine was able to logon to Exchange via POP3 and retrieve e-mail. Don't know why tcp/ip got corrupted, but somehow it must have. Glad I 'stumbled' upon the comments of someone who 'stumbled' upon the solution.
Well, I got my CRM back and it's been running fine, except for a bit of a headache left over. My Reporting Services still don't work. This is as expected so I have been trying to reinstall SRS. Unfortunately whenever I try to either install or even uninstall, I get the error "
This patch package could not be opened. Verify that the patch package exists and that you can access it, or contact the application vendor to verify that this is a valid Windows Installer patch package." This was quite frustratng but I went to my friend, Mr. Google. I searched for my problem and found articles that dealt with Microsoft Office XP and other programs, but not CRM nor SRS. But I decided to check one out. It suggested downloading the MSI Cleanup Utility,
msicuu2.exe. Following the instructions of
Microsoft KB 295823 I downloaded and installed msicuu2. I gave it a run and there listed, along with many programs, was Microsoft SQL Reporting Services. I selected it and clicked on Remove. It whirred and clicked a bit and finished. I then once again tried installing SRS and this time I was able to do so! Yea!! Now I still have a number of other things to do but at least I'm past this bump in the road.
For most of this week I have been battling a broken CRM. Luckily, with the great integration with Outlook, I have been able to continue functioning. Such would not have been the case with other systems like ACT! or GoldMine.
Basically it started with my trying to reinstate SQL Reporting Services after I did a full uninstall and reinstall. When I did RSCONFIG as part of the SRS reinstall, things started to go bad. Then they got worse. And then they got really bad! Everytime I did something I basically dug myself a deeper hole. I uninstalled CRM and reinstalled from scratch several times. My main 'issue' was a pesky Authentication Error that would come up and block me everytime I tried to access my CRM. Makes CRM pretty useless.
I kind of figured it was a security group problem. At first I thought it might have been because I had deleted the legacy security groups created by CRM 1.2. However, in my 'studies' in this crisis, I found that those could be deleted without problem. Then I figured it had to do with the 4 security groups that CRM 3.0 creates (PrivUserGroup, ReportingGroup, SQLAccessGroup, and UserGroup) and uses. It seems these groups have GUIDs (Globally Unique IDentifiers) associated with them. Each time I would reinstall CRM, from scratch, it would create new groups with new GUIDs.
On one of my attempts, I decided to reinstall using the defaults instead of having it use my specially created web site and such. I was surprised to find it that I still had the same problems with SQL Reporting Services validation, just as I had had with my custom installs. But I kept on and, using my newly created databases, I was able to add my user and bring up the (empty) CRM database. Yea! Then I restored my real data using the SQL restore function. Back to my ole nemisis 'Authentication Error'! This told me that somewhere in the SQL data there was something that was looking for something else. I still think it's the CRM security groups. (At one point I had deleted the original 4 CRM groups in a 'clean up' while trying to install from scratch.
Today I decided, finally, to try restoring my Active Directory from (System State) backup. There were my old security groups! Yippee. Still didn't work though. No problem thinks I, I'll just uninstall CRM and reinstall from scratch, as I'd done so many times before, and then restore my data again but with good AD groups. Oops! Not so fast. Now the system wouldn't let me uninstall! It was missing stuff in the registery it said. Well, the registry is what gets restored (along with other stuff) in a System State restore. Seems there was a mismatch now between the CRM install/uninstall routines and my 'new' registry. I spent a good bit of time trying to hack the registry (I am a brave soul sometimes). The harder I hacked, the deeper my hole became. Who was it, Will Rogers, said when you find yourself in a hole, stop digging?
Well, I get the bright idea to try restoring all my old CRM code stuff. I go back to my backups and restore the c:\program files\Microsoft CRM files and the e:\CRMWeb (where my CRM web stuff is kept). And then I go back and do an Active Directory Restore Mode (gotta go into that special mode) to once again restore my System State (my registry was pretty beaten up after my hacking episode this evening). Ouila! I now have my CRM system back!!
I guess there's nothing like having a good backup. I had been relying on the backup of my main CRM data in SQL but the other stuff turned out to be just as important, especially the registry and Active Directory data restored via System State.
Once I finally got it working again, my wife said 'I bet you learned a lot'. Yup. I think I did. Pain is a good teacher.
Today I set up a brand new SBS 2003 Premium server for a client. Everything went well except that whenever I attempted to access the Companyweb, I would get 404 errors. At first I thought that I might have a DNS issue since I'd just reconfigured an existing network that used a broadband router for its DHCP, DNS, etc. Nope that wasn't the case. I messed around a bit more and then went on to other chores.
Tonight I remoted in and tried again. First, I could not bring up Remote Web Workplace so I used RDP which worked fine. I tried RWW from the remote desktop and it still wouldn't work, as expected. Wondering why I was getting these errors, I did some head scratching. For some reason I decided to check the version of ASP.NET being used by the sites. I find that it is using ASP.NET 2.0. Hmmmm. So I change it on Companyweb to 1.1.4322 and try Companyweb again. Eureka! Up comes Companyweb. Well, at its normal snail's pace that is, but up it still comes. I try this on the Remote virtual web site and am able to bring up RWW. I check my own server and find my entire Default web tree is using 1.1. Don't know why the new SBS 2003 SP1 install used 2.0. It was a fresh install on a new box with brand new OEM software. I hadn't gotten around to doing updates yet.
So, if you find you can't get to Companyweb or other standard SBS 2003 web sites, check the version of ASP.NET the sites are using.
This Easter Saturday, my wife, daughter, and I took a jaunt to the Napa of Texas, the Texas Hill Country Wine Country. We started in Fredericksburg, about an hour northwest of San Antonio and had a bit of lunch. We (I don't know why) resisted the FredericksburyWinery but went East on US 290 towards Stonewall, Texas and hit Bell Mountain's tasting room. They gave us a rapid fire taste of ALL their wines. They were great! Then on to Grape Creek where we sampled some of their fairs. We passed up another that will remain unnamed but did have a large and full parking lot, and hit Becker.
Becker Vineyards is a relatively large winery with excellent wines. We sampled their tastings and then ordered a glass to enjoy sipping on their porch. As we were sipping, a young man with gorgeous girl friend kept looking at me. I wondered why when he finally came over and said "I know you!". He introduced himself as Jason from New Horizons in Austin. They were touring the Hill Country wineries as well, but in a limo! After a pleasant chat, they headed off to the next winery in the circuit, Woodrose. Well, Woodrose has, in my opinion, the best Cabernet Sauvignon in Texas. We finished our wine at Becker and headed to Woodrose. Jason's group's limo was parked outside the tasting room. After we'd been there a few minutes, Jason approached me once again but brought with him Randy Stanton (any relation, Anne?) and Randy Steinle of Systems Evolution and president of the Austin IAMCP chapter. It was good to catch up with Randy Steinle as he will be taking over the San Antonio office of Systems Evolution.
Looks like taking a limo tour of the Texas Hill Country wineries is a great and responsible way for Microsoft partners to build relationships. Perhaps the San Antonio IAMCP chapter, or maybe even our APCO SBS SIG, could learn a bit from this. They were going to finish their tour back in Austin at the Hofbrau with 'steaks swimming in butter'. Yum Yum!
No place else but Texas!
Since I attempted to install CRM Mobile 3.0 and got screwed up with UserGroup errors, I have been receiving DCOM errors everytime I close an activity in CRM. So, having mostly finished my taxes (my extension) I decided to revisit the issue. I attempted to do a Repair of CRM but it told me it couldn't because the groups weren't correct. Of course correcting these groups was my intent in doing the Repair. I finally decided that perhaps doing an Uninstall followed by a reinstall might clear things up. I've done several uninstalls and reinstalls to my existing database so I figured that wouldn't be too bad. Wrong! The reinstall failed because the groups weren't right. Aaarrrggghhhh!!!!
To make a long story short(er) I decided to install to new databases. Of course I did a backup of my existing databases first, and I made copies of the actual files as well. I also had to rename the OU (Organizational Unit) in Active Directory that houses my CRM as well as the CRM generated groups contained therein, at least the four of concern. There are others for the various CRM roles that I haven't delved into yet but they may pose another issue. We'll see. I followed Handy Andy's procedures for installing as cronicled yesterday. Unfortunately, I still encountered problems with SQL Reporting Services like I have in the past. I'll have to revisit my resolution of that later.
SBS MVP Andy Goodman, aka Handy Andy, must be jockeying for a dual MVP award to include CRM. He has just posted great and very detailed explanation of his experience installing CRM 3.0 SBE on his SBS 2003 system. He details how to avoid the many traps we've encountered with ISA and puts in graphic terms (lots 'o screen shoots) how he proceeded. I recommend you check it out at http://www.sbs-rocks.com/CRM/CRMsbeInstall.htm.
Thanks, Andy!
Well, tonight I reloaded MS VPC and loaded the Service Pack that wiped out VPC yesterday. Everything seemed to go OK. My old VPC instances were still there although I did have to wipe out changes that had been made. No big deal, but it could have been. I also had to reinstall the Virtual Machine Additions for each VPC. Plus, I don't notice any improvement in performance. But then I haven't had a chance to exercise it. much yet.
Well, the buzz around town is that Microsoft is finally setting up an office here! It's only 600 feet in an office suites but it's a start. I heard from at least a couple of non-computer types today about it so the word is getting out.
I happened upon the blog of a respected CRM guru who was commenting on how Service Pack 1 (SP1) for Microsoft Virtual PC 2004 can help speed up the performance of the CRM 3.0 Demo VPC. My demo is 'OK' but I decided to download it anyway. (
It can be found here). It appeared to download OK but when I tried to install it, it appeared to have an error or two. What happened next is kinda weird though. The install actually reported that it had completed successfully (eventhough I reported numerous errors) but when I go looking for VPC, it is nowhere to be found! It is no longer on the menu. It is no longer on my C: (only) drive as far as I can tell. VPC has disappeared! Apparently the Service Pack uninstalled (completely) my VPC! I'll have to reinstall (soon - I have to do a Swing this week). I'll report back if I run into any further hiccups.
Today, I installed the CRM 3.0 desktop client on a workstation that I personally haven't used much for some time. I apparently haven't checked my e-mail, etc. for quite some time. But I decided to go ahead and install the client before I allowed my Outlook to 'catch up'. It is (was) in cache mode. When I loaded CRM, I got a bucket full of 'Reminders' for old appointments, real old. That wasn't too bad. Then I went back to my everyday machine, my notebook. I fired up Outlook and it went crazy! For I don't know how long it keep a steady stream of messages going that the appointment record was Read-Only in CRM and could not be updated (I'm assuming old Activities that had been closed) and then I got a lot of 'Larry is not available' messages to appointments. Well, I finally got through all those and figured I was home safe. Then tonight I fired up CRM and found that I had a couple of years, well ever since I started using CRM, OK, about a year ago, worth of old appointments, etc. that were showing again! I'm going through them, closing them.
So, I guess my advice would be before you install the CRM Outlook client, be sure the Outlook is updated and synched up first. Not sure that was the problem, but sure seems that way.
This morning I decided to try doing a Repair on my CRM 3.0 installation. This is done by running the CRM installation (SetupServer.exe) from the installation CD. The routine recognizes that CRM is already installed and gives you the option to either Repair or Uninstall. When I attempt to Repair, it goes through its pre-installation checks and bombs out because there is a problem with the groups. I KNOW there's a problem with the groups. That's what I want to REPAIR. Repairing the groups is apparently not an option in the Repair mode.
The error I get is
Active Directory Group Cannot Be Found
Cause
The Active Directory group cannot be found. There can be several causes for this, including:
- No Active Directory group was specified
- The specified Active Directory group does not exist (it may not yet hae been created)
- The specified Active directory group is invalid
- The specified Active Directory group type is invalid
Solution
The four security groups listed below must be created in Active Directory before using the Precreate Groups option in the Microsoft CRM setup config file.
- PrivUserGroup
- SQLAccessGroup
- UserGroup
- ReportingGroup
_____________________________________________________________
Well, unfortunately I have to go fry my brain on my taxes. Uncle Sam wants is due next week and he has a bigger stick than my need for CRM Mobile at the moment. When I need a break from Tax frying, I'll come fry the other side of my brain on this again.
Continuing on with my attempt to install CRM 3.0 Mobile on my SBS server: I have (had) two security groups names UserGroup. Each group had a GUID in its name. I searched the registery for each GUID and neither was found. I then queried an Irish friend (still recovering from St. Paddies day I believe) who is running CRM 3.0 without Mobile and he had no groups named UserGroup. I then removed each group in turn from my system (maybe a mistake!) After each removal, I receive the error "Setup was interrupted before Microsoft CRM Mobile could be installed. To restart installation, run Setup.exe." Needless to say, running Setup.exe produces the same error message.
Stay tuned!
Well, I've been playing around trying to figure out why I can't install the server side of CRM 3.0 Mobile. The error relates to MyDomain\UserGroup and error 1609. Googling gives no useful information. However, inspecting my Active Directory and my Security Groups yields some interesting information! Seems there are TWO UserGroup security groups in my active directory!! I'm thinking one of them is a carryover from the old CRM 1.2 Mobile I once had installed.
Investigating the two groups, I find one has as members the users of my CRM system which are offered as choices when selecting the account to use for installating CRM 3.0 Mobile. The other has 'UserGroup' as the only member. Seems a bit recursive to me. The one with the actual users as members is a member of the ReportingGroup{GUID} and the UserGroup. The other is a member of SQLRepl. SQLRepl as I recall is probably a carryover from CRM 1.2 which used SQL replication. I'm going to take a chance and do away with the second UserGroup and see what happens.
OK. Well, it didn't like that very much at all. I renamed the 'old' group to UserGroup_1.2 and the setup routine wouldn't even ask me to accept the License Agreement. Let's see what happens when I rename the other... Well, back to where I started. Will play some more and blog later. Stay tuned.
Heavy on the 'attempting'.
Well, I decided to take a break from frying my brain working on taxes and instead roast it trying to install CRM Mobile. I've read Chapters 1 and 2 in the volumnus documentation and moved on to Chapter 4, Installing CRM 3.0 Mobile: Windows Small Business Server Scenarios. On my SBS server, I'm bringing up the CRM Mobile installation files and going for the Setup.exe. This first asks me to select my desired configuration. I select Microsoft Windows Small Business Server 2003. Then I accept the License Agreement and am taken to the Select User Account and Database Configuration. Here I am given the the choice of which CRM User Account to use to install and run CRM Mobile. I select the Administrator account. I then can select whether to create new databases for the CRM Mobile or use existing ones. Existing ones would be good if you are reinstalling CRM Mobile, I'd suspect. I select to create new CRM Mobile databases and hit Next. The Ready to Install Microsoft CRM Mobile window tells me what I just told it and then offers up the Install button which I (naturally) select. The Installing Microsoft CRM windows appears with a progress bar and then I get an error :-( It reads "Error 1609.An error occurred while applying security settings. LCS\UserGroup is not a valid user or group. This could be a problem with the package, or a problem connecting to a domain controller on the network. Check you network connection and click Retry, or Cancel to end the Install." Hitting 'Try Again (there is no 'Retry' button) just continues to repeat the error. So, I eventually hit Cancel.This ends the attempted install and I'm back pretty much where I started from.
Gotta track down what's going on. Will let you know when I do. Check back soon.
More Posts
Next page »