Tuesday, January 13, 2009

Platform: Windows Server 2003 (including R2)
Application: Windows Sharepoint Services (in this case version 2.0)

Best practices are to try upgrading in a lab before taking the plunge with new apps. We're in the process of moving our old Sharepoint Team Services app up to version 3.0, and I wanted to tinker with it in a lab environment before I went for it.

Fortunately, most of our environment is currently virtual machines (VMWare). So, I found a downtime to copy those guests over to my desktop, set up an isolated network (vmnet2) and bound the NICs to that network. I copied over my IIS server with sharepoint on it, Created a separate SQL Server and restored recent backups of the sharepoint databases, and one of our domain controllers/dns servers so the other 2 machines had a DC to talk to.

I kept getting the dreaded "#50070: Unable to connect to the database." error in the system log of the Sharepoint server for the Sharepoint Timing service. Lots of people get this error, and it's frequently related to connectivity issues. I dug through a lot of the options presented on EventID.Net and none seemed to match my situation.

Eventually I started checked the user permissions on the SQL server, and realized I couldn't browse the network. WTH! The Sharepoint server could see the network (remember this is my sandbox that really only has 3 machines). Then a big lightbulb came on when I realized I had not joined the SQL server to the sandbox network! I had created it from scratch, installed SQL server, restored my database backup, but never did I join it to the domain so all the Sharepoint services did not work, nor was I able to connect (got another error there).

So, if you ever find yourself in this situation, make sure the darn SQL Server is in the domain! :-)

Saturday, March 22, 2008

Platform: Windows XP

This past week I was working on a network integration for a business my current company bought. We inherited their outdated installation of MAS 200 from Best Software (ahem, the audacity). Anyhow, we replaced their "suitable only for m0n0wall" 6 year old beige-bomb computers with state o' the art HP Desktops with widescreen displays. Everything worked fine, reinstalling the software on the new profiles worked great.

Except there were "sporatic" problems. Several of the dialogs for MAS have scrolling windows of line items, and we were getting complaints that the users could not highlight the line items at times. Click and nothing happens.

Our local deputy-IT tech figured it out. It turns out this app cannot handle working on the new widescreen 16:10 displays. If the dialog box appears beyond the area that corresponds to the 4:3 section (approximately the left 2/3's of the display) and the user tries to click on the line items in the dialog box, the clicks are ignored. Move the dialog box to the left 2/3's of the screen, and it works. I've NEVER seen anything like this before. We even determined if the window was positioned on the imaginary Mason-Dixon line between the 4:3 and 16:10 spots, you could click the line items on the left hand side of the dialog, but not the right. Note that scrollbars on windows worked fine, as did buttons. Just the line items were affected.

So, the "solution" has a few possibilities. In some cases, we ran the widescreen displays with a 4:3 resolution (i.e. 1024X768 or 1154X864) which of course results in fat wide video that's not crisp. Religiously speaking, I'm opposed to this but many of the users liked the larger display and didn't mind the "fat" view. The other solution is to move the dialog boxes over when a user discovers the window isn't clickable. I'm sure there's a patch or update that negates this issue, but this app is going to be replaced by others in the near future so we're not interested in going through all the other maintenance headaches to change it.

So, if your windows don't work, did you recently switch to a widescreen display? Strange.

Thursday, January 18, 2007

Platform: Windows XP, 2003, Vista (PowerShell)

If you're not using Windows PowerShell, you should be. Here's a way I figured out how to flatten a path into a single directory. In my case I had lots of pictures in different folders that had unique names, so it was a matter of doing the following:
gci --recurse . *.jpg | cpi -dest 'c:\flat'

gci, or get-child-item, gets all the files in this directory. It follows all subdirectories with the "--recurse" option. I ran this in the current directory, hence the "." and I just wanted all my JPEG pictures.

Then, pipe it out to cpi cmdlet (copy item) with a -dest and your destination path. It worked GREAT. In the past on Windows I've either done this with Cygwin or with other utilities like XXCOPY ($$$). Free is good, and I'm just getting my feet wet in PowerShell now.

Other sites have discussed this as well.

Tuesday, October 10, 2006

Platform: Windows XP/2003 (might work with older too)

Now that I'm heavily into virtualization and doing a bunch of physical to virtual (P2V) moves, I end up having NIC conflicts on IP addresses with abandoned NICs that will never make their way back into my system. Of course Windows says "you already have this IP address on another adapter" when I set my new NIC as a virtual machine guest to the same IP as the old physical adapter had. So how to delete the old adapters? It's not like I can put them back in (it's a virtual machine now!) and remove them from device manager. Here's the process:

Drop into a command line.
Type in "set devmgr_show_nonpresent_devices=1"
(don't use quotes, we just set a shell variable)
Type in "devmgmt.msc" This will launch the Windows Device Manager Console.
In the Device Manager Console, from the "View" menu, select "Show Hidden Devices".

From here you can select the old NICs or other devices long gone from your system (the icons will be somewhat lighter than valid ones) and uninstall. Note, really really bad things can happen if you remove something you need, so only take out the NICs you know you can blow away.

Friday, June 30, 2006

Platform: Linux, Mac OSX, Windows - Firefox

Wondering where the cache is at? Type about:cache in the address bar and you'll get info on the path and be able to view content info as well. I searched Google for a while, and maybe this is a beginner tip for most, but I had a bear of a time finding it. Tip: On Windows it's buried in the local profile Application Data folder.

Wednesday, August 03, 2005

Platform: Windows Vista Beta 1

As a followup to the "magical shift-f key" post I did a while back, I tested it out today on a Windows Vista Beta 1 install. I was able to do the Shift-F10 trick to get a command prompt and thus run taskmgr, but the Shift-F11 wouldn't give me any detail about what was being installed. So, this little hack "half" works for Vista.

Monday, July 11, 2005

Platform: Windows (Tested on XP)

Ever heard of IEXPRESS.EXE? Neither had I, so I ran it. It's a simple app that develops self-extracting packages that are like Microsoft patches. The app can be used to created Cabs, extract files, or extract and run a .EXE after extraction. In a small network, it could be a very easy and cheap way to distribute something. This app was just automatically on my system, using XP Pro SP2.