If you have virtual servers (VMWare, Hyper-V, Virtual Box, etc.) running Windows operating system that does not have Internet connectivity; you will see the operating system services run slow. An example is opening up PowerShell command prompt. This could take up to 30 seconds at times. Open Internet Explorer. Then open an internal website. This could take some time.
Want to know why?
[box type=”info”]Here is the answer:
It’s a known issue with Windows. It’s trying to check certificates to see if they have been revoked. However, it slows down the operations within the operating system until the check times out. [/box]
To avoid this issue, you can fix the issue a couple of ways. Manual or script it with PowerShell.
Go to Tools => Internet Options =>Advanced tab => Under Security: uncheck “Check for Server Certificate Revocation(requires restart)[/box]
[box]Set-ItemProperty -Path HKCU\software\microsoft\windows\currentversion\internet settings\ -Name “CertificateRevocation” -Value =”0″[/box]
[box type=”bio”]A special thank you to John Chism and his team for coming up with this solution.[/box]
Ok, I was thinking that I could quickly take a SharePoint 2007 content database, apply the minimum Service Pack 2 for WSS 3.0 and MOSS 2007, and then perform a database attachment within SharePoint 2010 in minutes while basking in the glory of the easy process. I should have known this is SharePoint and everything is earned in this world. 🙂
I rebooted all the web front end servers and application servers just to make sure my little SharePoint 2007 world had the right build number of 184.108.40.20621 within Central Admin. So I did a backup of the database and then moved the BAK file to the SharePoint 2010 Database instance and performed a simple restore. For extra incentive and I was the DBO in the environment, I placed the SP Farm Account DBO to make sure the attachment goes ok.
I ran the PowerShell commandlet Test-SPContentDatabase to verify the database. Then I got the error.
[box type=”warning”]Category: DatabaseValidation Error: True UpgradeBlocking: False Message: This database [SSPBeta] is too old and cannot be upgraded. Remedy: Upgrade this database to Windows SharePoint Services Version 3, SP2 or later. [/box]
[box type=”info”]So after I read multiple blogs, forums, etc.; I wanted to think outside-of-the-box. I tried an idea. “Maybe the commandlet needed a build number newer than 220.127.116.1121?”
So I got the April/2009 Cumulative update for WSS 3.0 and MOSS 2007. So I applied these two CU’s to the SharePoint 2007 Environment.
I verified I was on build number 18.104.22.16804. [/box]
Just like washing your hair. Rinse and Repeat.
So I did a backup of the database and then moved the BAK file to the SharePoint 2010 Database instance and performed a simple restore. For extra incentive and I was the DBO in the environment, I placed the SP Farm Account DBO to make sure the attachment goes ok.
I ran the PowerShell commandlet Test-SPContentDatabase to verify the database.
[box type=”shadow”]Then Poof!!! The Test-SPContentDatabase command liked this minor build update.[/box]
Resources for review:
I welcome any feedback.
There are times where I need to view a website but the website is not ready for Internet Explorer 9. But how can I change Internet Explorer 9 so that I can view it in compatibility mode?
Well in Internet Explorer 9, the location is buried. So I am writing this blog post so I can reference it. I am sure there are other fellow technologists out there that need the same information. I hope this helps people out.
[box]1. Right Click on the sprocket on the top-right hand side.
2. Checkmark Command bar. (You should now see the command bar.)
3. Choose Tools ==> Then Compatibility View Settings.
4. Then Kapow! You are now view it in other IE settings. [/box]
So I took a SharePoint 2007 SP2 compliant and tested content database and placed it into a SharePoint 2010 enviornment. All the content was there. The permissions were fine. However, by database attachment went to a new SharePoint 2010 web application that had a different URL name.
Example: intranet.company.com SP 2007 content database was attached to sp2010dev.company.com
This URL change throws off alerts. You can delete the alerts and add them back in but that is just crazy to think about that scenario. And guess what…..there is a PowerShell commandlet to fix this issue. But unfortately, this answer is buried on search engines.
Anyway, there is the PowerShell commandlet.
[box]Invoke-AlertFixup -site <NewURL> -oldurl <OldURL> [/box]
Here is the exact Technet article to reference.