Someone just pointed me to the following site:
SharePoint PowerShell Command Builder
A really nice tool for SharePoint administrators who are new to PowerShell.
Note: Silverlight is required!
Wednesday, February 29, 2012
Wednesday, February 15, 2012
Moeten bedrijven strafrechtelijk vervolgd worden na hack?
[Apologies to non-Dutch speakers for this Dutch post]
De afgelopen week is bekend geworden dat KPN de dupe is geworden van hackers. Nu meer en meer informatie naar buiten komt, blijkt dat deze hack grotendeels mogelijk is gemaakt doordat ze hun zaakjes niet op orde hadden (http://tweakers.net/nieuws/79918/hack-bij-kpn-kinderlijk-eenvoudig-door-verouderde-software.html). De hackers schijnen zelfs toegang gehad te hebben tot de core componenten van hun netwerk infrastructuur en zouden daar de mogelijkheid gehad hebben om klanten af te luisteren of af te sluiten.
Hacks
De laatste tijd zijn steeds meer bedrijven/instellingen het slachtoffer van hackers. Een aantal pakkende voorbeelden hiervan zijn:
Oorzaak
Als de achterliggende feiten bekend worden, blijkt het beheer van de IT omgeving abominabel slecht! Alle security best practices worden met voeten getreden, niet heel onlogisch dus dat ze een keer de klos zijn. Slechte wachtwoorden, ongepatche systemen, verouderde systemen, slechte inrichting en slechte code zijn maar een kleine selectie van oorzaken. Vele van de bovenstaande hacks waren te voorkomen geweest als men hun huiswerk had gedaan en zich aan de bekende security best practices had gehouden:
Persoonsgegevens
Veel bedrijven willen tegenwoordig alles van je weten; NAW gegevens, e-mailadressen, gebruikersnaam/wachtwoorden, creditcard gegevens, noem het maar op. En alles wordt in databases opgeslagen. De gevolgen kunnen enorm zijn als deze informatie op straat komt te liggen doordat bedrijven laks met deze gegevens omgaan??
En wat nu?
Wat ik mij op dit moment afvraag: Moeten bedrijven niet strafrechtelijk worden vervolgd als persoonsgegevens door hun nalatigheid op straat komen te liggen? Het toevallige is dat de afgelopen week een vergelijkbaar iets ook publiekelijk afgevraagd word:
“CBP wil bedrijf boete geven bij hackincidenten”: http://www.telegraaf.nl/digitaal/11511512/__CBP_wil_bedrijf_boete_geven_bij_hackincidenten__.html
“Geef KPN megaboete”: http://www.telegraaf.nl/digitaal/11510372/___Geef_KPN_megaboete___.html
Nu hoor ik mensen al roepen
Als ik thuis mijn deur open laat staan en iemand neemt mijn televisie mee, moet ik dan ook vervolgd worden? Dit is echter een andere situatie en is het antwoord dus "nee", voornamelijk doordat je hier alleen jezelf mee heb. Ik ben de enige die geen tv meer kan kijken, niemand anders heeft hier last van.
Ook is het zo dat een gemiddelde fietsverzekering niet uitbetaald als je niet twee originele sleutels kunt overleggen. Zet je hem dus niet op slot, is dat je eigen schuld.
Conclusie
De meeste bedrijven denken veel te licht over beveiliging: http://www.telegraaf.nl/digitaal/11514835/___Bedrijven_denken_te_licht_over_beveiligen___.html
Door persoonlijke gegevens op te slaan, verplichten bedrijven zich tot het veilig houden van deze gegevens. Kunnen of willen ze dit niet, verwijder ze dan na de transactie en voorkom zo dat ze op straat komen te liggen. Echter is het vaak de (commerciële) waarde van deze gegevens voor mailings en andere marketing activiteiten die voorkomt dat deze gegevens verwijderd worden. Business gaat dan voor beveiliging.
NOTE: This article is my personal opinion and does not reflect the opinion of my employer or anybody else.
De afgelopen week is bekend geworden dat KPN de dupe is geworden van hackers. Nu meer en meer informatie naar buiten komt, blijkt dat deze hack grotendeels mogelijk is gemaakt doordat ze hun zaakjes niet op orde hadden (http://tweakers.net/nieuws/79918/hack-bij-kpn-kinderlijk-eenvoudig-door-verouderde-software.html). De hackers schijnen zelfs toegang gehad te hebben tot de core componenten van hun netwerk infrastructuur en zouden daar de mogelijkheid gehad hebben om klanten af te luisteren of af te sluiten.
Hacks
De laatste tijd zijn steeds meer bedrijven/instellingen het slachtoffer van hackers. Een aantal pakkende voorbeelden hiervan zijn:
- KPN: http://tweakers.net/nieuws/78630/kpn-haalt-site-gemnet-offline-na-beveiligingsprobleem.html
- InHolland: http://tweakers.net/nieuws/78358/inholland-haalt-sites-offline-na-hack.html
- Sinterklaasjournaal: http://tweakers.net/nieuws/78252/gegevens-13000-kinderen-toegankelijk-door-lek-sinterklaasjournaal-punt-nl.html
- Diginotar: http://tweakers.net/nieuws/73411/comodo-geeft-frauduleuze-ssl-certificaten-uit-na-hack.html
- Gemeentes: http://tweakers.net/nieuws/77290/vijftig-gemeentesites-blijken-nauwelijks-beveiligd.html
- Gemeente Amsterdam: http://tweakers.net/nieuws/76892/diverse-gaten-ontdekt-in-website-gemeente-amsterdam.html
- Creation Point/Bavaria: http://tweakers.net/nieuws/79987/hacker-krijgt-toegang-tot-database-hostingprovider-bavaria.html
- Philips: http://tweakers.net/nieuws/80016/hacker-steelt-e-mailadressen-uit-database-philips.html
Oorzaak
Als de achterliggende feiten bekend worden, blijkt het beheer van de IT omgeving abominabel slecht! Alle security best practices worden met voeten getreden, niet heel onlogisch dus dat ze een keer de klos zijn. Slechte wachtwoorden, ongepatche systemen, verouderde systemen, slechte inrichting en slechte code zijn maar een kleine selectie van oorzaken. Vele van de bovenstaande hacks waren te voorkomen geweest als men hun huiswerk had gedaan en zich aan de bekende security best practices had gehouden:
- De hack die gebruikt is bij de 50 gemeentes: Het misbruikte probleem (Unicode hack) is al bijna 10 jaar bekend en verholpen in alle nieuwe software sinds 2002/2003.
- De hack die gebruikt is bij het Sinterklaasjournaal: Hier werd door een gebruiker ingevoerde gegevens zonder validatie door de website gebruikt (SQL injection), met alle gevolgen van dien. Een best practice die ook al jaren bekend is en hier dus niet gevolgd is.
Persoonsgegevens
Veel bedrijven willen tegenwoordig alles van je weten; NAW gegevens, e-mailadressen, gebruikersnaam/wachtwoorden, creditcard gegevens, noem het maar op. En alles wordt in databases opgeslagen. De gevolgen kunnen enorm zijn als deze informatie op straat komt te liggen doordat bedrijven laks met deze gegevens omgaan??
En wat nu?
Wat ik mij op dit moment afvraag: Moeten bedrijven niet strafrechtelijk worden vervolgd als persoonsgegevens door hun nalatigheid op straat komen te liggen? Het toevallige is dat de afgelopen week een vergelijkbaar iets ook publiekelijk afgevraagd word:
“CBP wil bedrijf boete geven bij hackincidenten”: http://www.telegraaf.nl/digitaal/11511512/__CBP_wil_bedrijf_boete_geven_bij_hackincidenten__.html
“Geef KPN megaboete”: http://www.telegraaf.nl/digitaal/11510372/___Geef_KPN_megaboete___.html
Nu hoor ik mensen al roepen
Als ik thuis mijn deur open laat staan en iemand neemt mijn televisie mee, moet ik dan ook vervolgd worden? Dit is echter een andere situatie en is het antwoord dus "nee", voornamelijk doordat je hier alleen jezelf mee heb. Ik ben de enige die geen tv meer kan kijken, niemand anders heeft hier last van.
Ook is het zo dat een gemiddelde fietsverzekering niet uitbetaald als je niet twee originele sleutels kunt overleggen. Zet je hem dus niet op slot, is dat je eigen schuld.
Conclusie
De meeste bedrijven denken veel te licht over beveiliging: http://www.telegraaf.nl/digitaal/11514835/___Bedrijven_denken_te_licht_over_beveiligen___.html
Door persoonlijke gegevens op te slaan, verplichten bedrijven zich tot het veilig houden van deze gegevens. Kunnen of willen ze dit niet, verwijder ze dan na de transactie en voorkom zo dat ze op straat komen te liggen. Echter is het vaak de (commerciële) waarde van deze gegevens voor mailings en andere marketing activiteiten die voorkomt dat deze gegevens verwijderd worden. Business gaat dan voor beveiliging.
NOTE: This article is my personal opinion and does not reflect the opinion of my employer or anybody else.
Tuesday, January 24, 2012
[SP2010/SPF] Required permissions to run command line tools or other tooling that uses the OM
[ISSUE]
With SharePoint in many cases the SharePoint administrators also are the Windows of the SQL server and/or SQL administrator. This means that those persons also having loads of permissions in SQL Server, which means that everything will work without issues. They can do anything they want, using any tool they want.
But what about a situation where you don't have permissions on SQL. You will see actions via the Central Administration site work fine, however certain things like console applications (custom like SharePoint Manage or default applications like stsadm), scripts via PowerShell and other tooling (basically everything that uses the object model) won't work.
This is caused by the fact that SharePoint requires the account to have certain permissions on the databases in order for it to work. When using the Central Administration, this is done via the application pool account which has sufficient permissions. When using the object model outside of the Central Administration, this is done under the account the command is executed with.
[SOLUTION]
Then which permissions are required? Here is where it becomes a little tricky!
PowerShell scripts:
More info: SharePoint 2010 PowerShell Permissions Explainedhttp://sharepoint.microsoft.com/Blogs/zach/Lists/Posts/Post.aspx?ID=56
With SharePoint in many cases the SharePoint administrators also are the Windows of the SQL server and/or SQL administrator. This means that those persons also having loads of permissions in SQL Server, which means that everything will work without issues. They can do anything they want, using any tool they want.
But what about a situation where you don't have permissions on SQL. You will see actions via the Central Administration site work fine, however certain things like console applications (custom like SharePoint Manage or default applications like stsadm), scripts via PowerShell and other tooling (basically everything that uses the object model) won't work.
This is caused by the fact that SharePoint requires the account to have certain permissions on the databases in order for it to work. When using the Central Administration, this is done via the application pool account which has sufficient permissions. When using the object model outside of the Central Administration, this is done under the account the command is executed with.
[SOLUTION]
Then which permissions are required? Here is where it becomes a little tricky!
PowerShell scripts:
- When you are running SharePoint 2010 and you are trying to use PowerShell, Microsoft has created a SharePoint internal group called ShellAdmins. By adding your account to this group (Add-SPShellAdmins) your account has sufficient permissions to run PowerShell scripts. Other activities via the object model still don't work.
Other tools:
- To enable all object model activities, grant the account the following permissions:
- SharePoint (Depending on the activities you are going to do)
- Farm Administrator
- Permissions in the site collection(s), for example site collection administrator or contributor to a list
- Database:
- Configuration database: WSS_Content_Application_Pools
- Content database:
- Db_datareader
- Db_datawriter
- GRANT EXECUTE
- NOTE: An alternative would be db_owner permissions on the content database, however from SQL administration perspective this might be unwanted/against policy
More info: SharePoint 2010 PowerShell Permissions Explainedhttp://sharepoint.microsoft.com/Blogs/zach/Lists/Posts/Post.aspx?ID=56
Tuesday, January 17, 2012
[SP ALL] Opening a web service is returning a 401.1 "Access Denied" error
[ISSUE]
Yesterday I was asked to assist in troubleshooting an issue with a SharePoint web service. The SharePoint indexing process failed to work properly for just one web application. Some investigation revealed that the indexer was unable to open the sitedata.asmx web service. When trying to open the same web service via IE, I was prompted for credentials however whatever credentials were entered, after three attempts an "Access Denied" page (401.1 error) was shown.
[SOLUTION]
Unfortunately Process Monitor didn't reveal anything and I noticed that the sitedata web service wasn't the only web service that failed. After some troubleshooting I found out that the cause was in the web config:
The "remove verb *.asmx" line was placed after the "add verb *.asmx" line in the httphandler setting, essentially removing the configuration after adding it. For example:
[EXPLANATION]
Why is this happening? By first placing the remove line, you make sure any declarations that are done in other (global) configuration files are made void. That way you know for sure that no conflicts will occur between two configurations. However after removing the asmx httphandler, you have to declare it again, else SharePoint (or better yet IIS) does not know how to handle the asmx file. The confusing part for this issue is that it will display an authentication prompt to the user, without it actually being an authentication issue.
Yesterday I was asked to assist in troubleshooting an issue with a SharePoint web service. The SharePoint indexing process failed to work properly for just one web application. Some investigation revealed that the indexer was unable to open the sitedata.asmx web service. When trying to open the same web service via IE, I was prompted for credentials however whatever credentials were entered, after three attempts an "Access Denied" page (401.1 error) was shown.
[SOLUTION]
Unfortunately Process Monitor didn't reveal anything and I noticed that the sitedata web service wasn't the only web service that failed. After some troubleshooting I found out that the cause was in the web config:
The "remove verb *.asmx" line was placed after the "add verb *.asmx" line in the httphandler setting, essentially removing the configuration after adding it. For example:
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />After correcting this by placing the remove line in front of the add line, all web services started working just fine!
....
<remove verb="*" path="*.asmx" />
<remove verb="*" path="*.asmx" />
....
<add verb="*" path="*.asmx" validate="false" type="System.Web.Script.Services.ScriptHandlerFactory, System.Web.Extensions, Version=3.5.0.0, Culture=neutral, PublicKeyToken=31bf3856ad364e35" />
[EXPLANATION]
Why is this happening? By first placing the remove line, you make sure any declarations that are done in other (global) configuration files are made void. That way you know for sure that no conflicts will occur between two configurations. However after removing the asmx httphandler, you have to declare it again, else SharePoint (or better yet IIS) does not know how to handle the asmx file. The confusing part for this issue is that it will display an authentication prompt to the user, without it actually being an authentication issue.
Friday, December 23, 2011
[SP2010/SPF] SharePoint 2010 Build numbers
Here a list of build numbers for SharePoint 2010. Based on the build number you can determine which patchlevel your SharePoint environment is on:
14.0.6114.5000 - December '11 CU
14.0.6112.5000 - October '11 CU
14.0.6109.5002 - August '11 CU
14.0.6106.5000 - June '11 CU
14.0.6029.1000 - Service Pack 1
14.0.5138.5001 - April '11 CU
14.0.5136.5002 - February '11 CU
14.0.5130.5002 - December '10 CU
14.0.5128.5003 - October '10 CU
14.0.5128.5000 - October '10 CU (Incorrect package)
14.0.5123.5000 - August '10 CU
14.0.5114.5003 - June '10 CU
14.0.4763.1000 - RTM
[MOSS2007/WSSv3] SharePoint 2007 Build numbers (Updated)
Here a list of build numbers for SharePoint 2007. This list is updated until the December '11 Cumulative Update:
You can find the build number of your environment via:
Central Admin > Operations > Servers in Farm
12.0.6656 - MOSS2007/WSSv3 December '11 Cumulative Update
12.0.6654 - MOSS2007/WSSv3 October '11 Cumulative Update
12.0.6608 - MOSS2007/WSSv3 Service Pack 3
12.0.6565 - MOSS2007/WSSv3 August '11 Cumulative Update
12.0.6562 - MOSS2007/WSSv3 June '11 Cumulative Update
12.0.6557 - MOSS2007/WSSv3 April '11 Cumulative Update
12.0.6554 - MOSS2007/WSSv3 February '11 Cumulative Update
12.0.6550 - MOSS2007/WSSv3 December '10 Cumulative Update
12.0.6548 - MOSS2007/WSSv3 October '10 Cumulative Update
12.0.6545 - MOSS2007/WSSv3 August '10 Cumulative Update
12.0.6539 - MOSS2007/WSSv3 June '10 Cumulative Update
12.0.6535 - MOSS2007/WSSv3 April '10 Cumulative Update
12.0.6529 - MOSS2007/WSSv3 February '10 Cumulative Update
12.0.6524 - MOSS2007/WSSv3 December '09 Cumulative Update
12.0.6520 - MOSS2007/WSSv3 October '09 Cumulative Update
12.0.6514.5004 - (Corrected) MOSS2007/WSSv3 August '09 Cumulative Update
12.0.6514.5000 - MOSS2007/WSSv3 August '09 Cumulative Update
12.0.6510 - MOSS2007/WSSv3 June '09 Cumulative update
12.0.6504 - MOSS2007/WSSv3 April '09 Cumulative update
12.0.6421 - MOSS2007/WSSv3 SP2
12.0.6341 - MOSS2007/WSSv3 February '09 Cumulative update
12.0.6335 - MOSS2007/WSSv3 December '08 Cumulative update
12.0.6327 - MOSS2007/WSSv3 August '08 Cumulative update
12.0.6318 - MOSS2007/WSSv3 Infrastructure Update
12.0.6300 - MOSS2007/WSSv3 post-SP1 hotfix
12.0.6219 - MOSS2007/WSSv3 SP1
12.0.6039 - MOSS2007/WSSv3 October '07 public update
12.0.6036 - MOSS2007/WSSv3 August 24 '07 hotfix package
12.0.4518 - MOSS2007/WSSv3 RTM
You can find the build number of your environment via:
Central Admin > Operations > Servers in Farm
Tuesday, September 13, 2011
[SP2010] Upgrade to SP2010 issue with missing content types
[ISSUE]
During a database upgrade from SP2007 to SP2010 I encountered an issue, which blocked a succesful upgrade. Several features could not be upgraded because of an issue with content types.
[ERROR]
[powershell] [SPSiteWssSequence2] [ERROR] [7/15/2011 1:14:56 PM]: Feature upgrade incomplete for Feature 'PublishingSite' (Id: 'f6924d36-2fa8-4f0b-b16d-06b7250180fa') in Site 'http://www.domain.com/sites/sitecollectionname'. Exception: The parent content type specified by content type identifier 0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF39 does not exist.
[CAUSE]
This issue is caused by the fact that:
- The publishing features (“SharePoint Server Publishing Infrastructure” and the features it is depending on) have been enabled and disabled in the past
- Content types have been deleted the incorrect way: Deleted while other components were still using them.
[SOLUTION]
The mentioned content type ID is the ID of the content type “Page”, which does not exist anymore in the Site Content Types. To recreate these, run the following stsadm commands for each site collection that is experiencing the issue (retrieve the list from the upgrade log file):
stsadm -o activatefeature -name PublishingSite -url <url> -force
stsadm -o activatefeature -name PublishingResources -url <url> -force
During a database upgrade from SP2007 to SP2010 I encountered an issue, which blocked a succesful upgrade. Several features could not be upgraded because of an issue with content types.
[ERROR]
[powershell] [SPSiteWssSequence2] [ERROR] [7/15/2011 1:14:56 PM]: Feature upgrade incomplete for Feature 'PublishingSite' (Id: 'f6924d36-2fa8-4f0b-b16d-06b7250180fa') in Site 'http://www.domain.com/sites/sitecollectionname'. Exception: The parent content type specified by content type identifier 0x010100C568DB52D9D0A14D9B2FDCC96666E9F2007948130EC3DB064584E219954237AF39 does not exist.
[CAUSE]
This issue is caused by the fact that:
- The publishing features (“SharePoint Server Publishing Infrastructure” and the features it is depending on) have been enabled and disabled in the past
- Content types have been deleted the incorrect way: Deleted while other components were still using them.
[SOLUTION]
The mentioned content type ID is the ID of the content type “Page”, which does not exist anymore in the Site Content Types. To recreate these, run the following stsadm commands for each site collection that is experiencing the issue (retrieve the list from the upgrade log file):
stsadm -o activatefeature -name PublishingSite -url <url> -force
stsadm -o activatefeature -name PublishingResources -url <url> -force
Wednesday, August 10, 2011
[SP2010] Service Pack 1 data storage changes
With the release of Service Pack 1 of SharePoint 2010, Microsoft has changed the Data Storage limitations of SharePoint 2010. The 200GB is no longer a hard limit:
Source: http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=988
- For a SharePoint content database up to 200 GB there are no special requirements and this limit is included for consistency.
- For a SharePoint content database up to 4 TB you need to additionally plan for the following two requirements:
- Requires disk sub-system performance of 0.25 IOPS per GB, 2 IOPS per GB is recommended for optimal performance.
- Requires the customer to have plans for high availability, disaster recovery, future capacity, and performance testing.
- And you need to review additional considerations in the TechNet Boundaries and Limits article.
- For a SharePoint content database over 4TB specifically for a Document Archive scenario you are required to additionally plan for the following:
- SharePoint sites must be based on Document Center or Records Center site templates and must be an archive scenario where less than 5% of content is actively read from each month and less than 1% of content is actively written to.
- Do not use alerts, workflows, link fix-ups, or item level security on any SharePoint objects in the content database. Note: document archive content databases can be the recipient of documents as a result of Content Routing workflow.
- Other specific limits changes being made at the same time:
- A new limit of 60million items in any one SharePoint content database
- The specific 5 TB limit per SQL Server instance has been removed. Instead you should work with a SQL Server professional to plan for database storage
Source: http://sharepoint.microsoft.com/blog/Pages/BlogPost.aspx?pID=988
Wednesday, July 20, 2011
[SP2010] Upgrade SharePoint 2007 content to SharePoint 2010 via the Database Attach method
Last week I performed an upgrade of SharePoint 2007 to SharePoint 2010 using the Database Attach method. Unfortunately the database upgrade "Completed with errors". However, the site collections were available in SP2010 without errors. Also changing the visual style to SP2010 worked just fine. Detaching the database and reattaching did not give me any error, but it didn't restart or continue the upgrade process. Then how to fix this:
Troubleshoot upgrade errors
Each upgrade process produces an upgrade log file, which displays each error and warning that is found during the upgrade. To successfully complete the upgrade process you will have to fix each error and restart the upgrade process to upgrade the remaining, not yet upgraded, site collections.
Restart/resume the database upgrade
Once you have fixed all upgrade issues, you have to restart the upgrade process. This can be done using the following PowerShell script:
Source: http://technet.microsoft.com/en-us/library/ff382638.aspx
However if the database still contains issues, the upgrade will fail again. Review the generated log file to check what the errors are and retrieve more info for troubleshooting.
Verify upgrade status
To verify if all components in the environment are upgraded successfully, run the following command:
This command generates a report that contains a summary at the bottom. The part marked bold is the important part and specifies that in all databases there are 16 site collections not upgraded yet, this number should be zero.
If you send the output of the command to file and search for the text "Needs Upgrade", you will find the site collections that aren’t upgraded yet:
Troubleshoot upgrade errors
Each upgrade process produces an upgrade log file, which displays each error and warning that is found during the upgrade. To successfully complete the upgrade process you will have to fix each error and restart the upgrade process to upgrade the remaining, not yet upgraded, site collections.
Restart/resume the database upgrade
Once you have fixed all upgrade issues, you have to restart the upgrade process. This can be done using the following PowerShell script:
Source: http://technet.microsoft.com/en-us/library/ff382638.aspx
$guid = Get-SPContentDatabase -Identity <dbname>
upgrade-spcontentdatabase -id $guid
However if the database still contains issues, the upgrade will fail again. Review the generated log file to check what the errors are and retrieve more info for troubleshooting.
Verify upgrade status
To verify if all components in the environment are upgraded successfully, run the following command:
stsadm -o localupgradestatus
This command generates a report that contains a summary at the bottom. The part marked bold is the important part and specifies that in all databases there are 16 site collections not upgraded yet, this number should be zero.
[9] content database(s) encountered.
[0] content database(s) still need upgrade or cannot be upgraded.
[43] site collection(s) are contained in the content databases.
[16] site collection(s) still need upgrade.
[82] other objects encountered, [0] of them still need upgrade or cannot be upgraded.
If you send the output of the command to file and search for the text "Needs Upgrade", you will find the site collections that aren’t upgraded yet:
<object>
<name>https://www.domain.com/sites/sitecollectionname</name>
<type>Microsoft.SharePoint.SPSite</type>
<level>6</level>
<status>Needs Upgrade</status>
</object>
Monday, July 04, 2011
[SP2010] Guidance on implementation of Service Pack 1 for SP2010
Check out SharePoint 2010 SP1 and the June Cumulative Update for SharePoint 2010 for guidance on implementing SP2010 Service Pack 1 and the June 2011 Cumulative Update
Subscribe to:
Posts (Atom)