One last post for today. Now I normally want this blog to stay focused on SharePoint & related products - like I said this is my virtual memory site, helps me remember stuff I worked on way back when - but I wanted to post about the Magic Jack.
I've gone wireless at home for some time now, but working from home I didn't want to chew up my cell minutes on those long conference calls. I had been using Skype, and was generally pleased with the quality and price, but I did have a few bad/dropped connections and on one conf call folks said I sounded like I was talking in a fish bowl 800 miles away. Not good, especially since the call was with some MS Professional Services folks!
Over the weekend the wife and I saw an ad on TV for The Magic Jack, only $19.95!! Ever skeptical, I decided to try it out anyway. I bought the kit at the local Radio Shack for $40, which includes the first year's service, and I gotta say, I'm impressed. The call quality is quite clear, it's easier to use than Skype - none of that 001 - 866 - 1235466 * thing to dial out, just pick up the phone and dial the number. I used it quite a bit yesterday and my audio was fine, and no one mentioned that fish bowl. Looks like a nice product.
If it turns out to be otherwise I'll let you know! There's a deal with it too, $60 for 5 years of service, instead of $20 per year (OK, $59.95 and $19.95 respectively but a spade is....)
Friday, February 27, 2009
DR with SQL backups and PSCONFIG
As promised...for my client we are only taking SQL Server backups of the databases used by SharePoint, although we may soon be taking disk image backups as well, but that's another story!
Anyway, I had to put together a DR plan documenting the steps to recover SharePoint. There's a great step by step on how to do this for Project Server, posted here. Great article, but there was one thing I didn't understand after reading this...what about my IIS sites? I wasn't sure if I had to create the IIS sites needed for my web apps before I ran that PSCONFIG CONFIGDB command.
Turns out is is NOT necessary. The first thing that command does is to unprovision the provisioned Central Admin site. We follow a standard deployment guide & use the same ports for Central Admin & the Shared Services Provider on all our installs, so even though I did use that same port in the steps prior to the PSCONFIG CONFIGDB step, not necessary. After unprovisioning the site, the process then creates the web apps, the IIS sites, links in the content databases, even for the SSP. Worked just fine.
Now, one last question...what about SSL? Does that also get configured after the IIS site is created? I doubt it, and I need to ensure the existing server's private key is saved off somewhere so we can reinstall it. I need to do one more test on the DR process, I'll let you know what happens.
Anyway, I had to put together a DR plan documenting the steps to recover SharePoint. There's a great step by step on how to do this for Project Server, posted here. Great article, but there was one thing I didn't understand after reading this...what about my IIS sites? I wasn't sure if I had to create the IIS sites needed for my web apps before I ran that PSCONFIG CONFIGDB command.
Turns out is is NOT necessary. The first thing that command does is to unprovision the provisioned Central Admin site. We follow a standard deployment guide & use the same ports for Central Admin & the Shared Services Provider on all our installs, so even though I did use that same port in the steps prior to the PSCONFIG CONFIGDB step, not necessary. After unprovisioning the site, the process then creates the web apps, the IIS sites, links in the content databases, even for the SSP. Worked just fine.
Now, one last question...what about SSL? Does that also get configured after the IIS site is created? I doubt it, and I need to ensure the existing server's private key is saved off somewhere so we can reinstall it. I need to do one more test on the DR process, I'll let you know what happens.
SSL Exporting to a .PFX....not!
Yesterday I had a bit of a panic. I had a change request scheduled to publish my Project Server site over to our ISA Server. Normally to do this, one goes into the Certificates MMC snap in, locates the Personal certificate assigned to the server, and export it as a .PFX file.
Well, the option to export to .PFX was grayed out, with a warning about "the associated private key cannot be found" - but on the screen where I view the SSL certificate, I was told that there is a private key associated with this certificate. Since ISA Server requires the private key, this was going to be a show stopper!
Digging around I did find one helpful post on the Verisign site: http://forums.iis.net/p/1154109/1888980.aspx
This post lead to me look in the directory C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys, and then further, I was able to locate the file (named with a GUID) in the MachineKeys folder with the time stamp of when we installed the SSL certificate. Turns out even though I'm domain admin, that folder was not owned by the local Administrators group, and that further that GUID named key was owned only by the guy who installed the cert and SYSTEM - Domain Admins & the box admins didn't have permissions to the file or to that folder.
So once I took care of that, changing the ownership on that GUID file & then granting Full Control rights to that key, I was then able to export the certificate as a .PFX file...big relief!!!
Well, the option to export to .PFX was grayed out, with a warning about "the associated private key cannot be found" - but on the screen where I view the SSL certificate, I was told that there is a private key associated with this certificate. Since ISA Server requires the private key, this was going to be a show stopper!
Digging around I did find one helpful post on the Verisign site: http://forums.iis.net/p/1154109/1888980.aspx
This post lead to me look in the directory C:\Documents and Settings\All Users\Application Data\Microsoft\Crypto\RSA\MachineKeys, and then further, I was able to locate the file (named with a GUID) in the MachineKeys folder with the time stamp of when we installed the SSL certificate. Turns out even though I'm domain admin, that folder was not owned by the local Administrators group, and that further that GUID named key was owned only by the guy who installed the cert and SYSTEM - Domain Admins & the box admins didn't have permissions to the file or to that folder.
So once I took care of that, changing the ownership on that GUID file & then granting Full Control rights to that key, I was then able to export the certificate as a .PFX file...big relief!!!
Monday, February 09, 2009
The Startup Disk Could Not Be Written To
Well that says it all, ey? I've been working on some DR testing (stay tuned, post coming!!) to recover a Project Server deployment. I created my original VPC, up to the point where the DR stuff kicks in - installation of SharePoint, mainly; so the VPC has the host OS, joined the AD domain, has SQL Server installed.
I copied the VPC at this point then finished up installing the rest of the components - SharePoint, Project Server, service packs, December update, etc.
When I then went to boot up the DR VPC, I was told very nicely that "the startup disk could not be written to"! The VHD file had only the Archive bit set, was not set to be read-only.
I am using Vista w/o SP1 as my host OS. I went into the security settings for the file & saw that the file has entries for System, Administrators & Users. I thought my ID is a member of Administrators, but Users was marked for read-only rights, no Modify or Write rights. So I added in Modify and Write, must have got it right (heh) because then the VHD worked just fine.
I copied the VPC at this point then finished up installing the rest of the components - SharePoint, Project Server, service packs, December update, etc.
When I then went to boot up the DR VPC, I was told very nicely that "the startup disk could not be written to"! The VHD file had only the Archive bit set, was not set to be read-only.
I am using Vista w/o SP1 as my host OS. I went into the security settings for the file & saw that the file has entries for System, Administrators & Users. I thought my ID is a member of Administrators, but Users was marked for read-only rights, no Modify or Write rights. So I added in Modify and Write, must have got it right (heh) because then the VHD worked just fine.
Subscribe to:
Posts (Atom)