Narazil jsem na codeplex.com na pěkný nástroj SharePoint Client Browser for SharePoint 2010 and 2013 – http://spcb.codeplex.com/
Na rozdíl od SharePoint Managera (http://spm.codeplex.com/) se umí připojit k O365 a pracuje na pozadí nikoliv s nativními knihovnami SharePointu (lze spustit pouze na serveru), ale komunikace probíhá na webových službách.
Pro ladění projektu na šabloně SharePoint 2013 auto-hosted je nutné vždy v solution projektu Visual Studia nastavit více projektů pro spuštění, jinak se VS nepodaří chytit správný proces a hlásí chybu chybějících symbolů “The breakpoint will not currently be hit. No symbols have been loaded for this document”
pravý klik na solution/řešení projektu
Set StartUp Projects
Multiple startup projects
u SP projektu i u projektu webové části nastavte Action na hodnotu Start
Provedl jsem zkušební upgrade Microsoft Dynamics CRM z verze 2011 na 2013 na stejném serveru, tedy bez instalace čistého a přesunu všech komponent a databází na nový, vše proběhlo překvapivě hladce.
Doporučuji se nejprve prohlédnou implementační příručku, zejména sekci podporovaného HW/SW + nově nepodporované funkce:
Zkontrolovat všechny dostupné aktualizace instalačního souboru (nic mi nenašlo)
Po zadání Product Key je zobrazen dialog výběru organizace k upgrade (upgrade je možné provést dodatečně, pokud máte více CRM organizací, stejně můžete při instalaci vybrat pouze jednu):
Ponechal jsem NONE, všechny organizace tedy převedu až po instalaci
Všechny AD účty jsem ponechal bez změn
Adresu email routeru si instalační setup nepamatuje, vyplnil jsem znovu
Poslední kontrola proběhla bez problémů:
Next –> Next –> upgrade běží….
5 minut, výsledek OK:
Restart serveru – jinak neprojde instalace reporting add-onů
Následně zpět nainstalovat Report Authoring Extension a Reporting Extensions (postup je identický s 2011, nenarazil jsem na žádný problém)
Znovu nainstalovat Email Router – po spuštění instalace nabídne upgrade, opět pouze Next –> Next
Nainstalovat language pack
Spusťte CRM Deployment Manager
Vyberte organizaci a v navigačním panelu Actions spusťte Upgrade organization
Opět kontrola, opět OK:
Next a opět běží upgrade (dlouho, cca 20 minut v závislosti na velikosti organizace) – to stejné pro všechny organizace
HOTOVO!
Hotovo je samozřejmě jenom z pohledu samotného upgrade procesu, nyní ještě spousta práce s kontrolou, zda vše funguje jako dříve
Termín předplacení klasického hostingu se blížil konci, rozhodl jsem se proto přesunout svůj malý blog do Azure. Přemýšlel jsem nad tím už delší dobu, ale za celou dobu jsem nenašel žádné rozumné důvody proč to udělat – a v podstatě ani teď nemám. Stávající hosting mi vyhovoval, respektive jsem měl jiné měřítko, nechtěl jsem nic konfigurovat a starat se o to, všechno fungovalo léta a to byla moje spokojenost.
Nakonec jsem se rozhoupal:
přesun mi trval asi 3 hodiny, včetně dat
nejvíce mi trvalo přijít na některé ověřovací kroky (doména v Office365, credentials k FTP)
všechno jsem dělal ručně, žádné wizady nebo aplikační market na Azure
zůstal jsem u BlogEngine.NET
v podstatě velice jednoduché
Jediné co mám pořád s otazníkem je, kolik celá ta sranda bude měsíčně stát….
SharePoint automaticky překládá všechny odkazy dle aktuální zjištěné URL zóny z HttpRequestu, je jedno zda máte odkazy přímo ve webpart stránce, ve sloupci typu Hypertextový odkaz, případně přímo v richtextu, SharePoint se vždy při renderingu podívá, zda odkaz není definován v AAM a pokud ano, automaticky ho přeloží na tvar přístupný aktuálně přihlášenému uživateli. Je to funkce logická a žádaná, neboť je jedno, zda vložíte do textu odkaz z intranetové či extranetové zóny (url adresy SP portálu), všichni uživatelé budou mít odkazovaný obsah dostupný vždy.
Stejné chování je potřeba přenést i do vlastně vyvinutých funkcí, webpart, aplikačních stránek – protože tam to SharePoint sám o sobě neumí. Převod je sám o sobě velice jednoduchý, základem je objekt SPSite, který je ale nutné buď převzít z kontextu SPContext.Current.Site nebo ho inicializovat pomocí aktuální Url adresy HttpRequestu – tedy tak, aby došlo k inicializaci objektu SPSite ve správné zóně (SPUrlZone), nelze tedy tento objekt inicializovat pomocí GUID, kde se informace o zóně ztratí.
Pro překlad odkazu mám triviální rozšíření objektu SPSite:
public static string TranslateUrlByAAM(this SPSite site, string url)
{
if (site == null)
throw new ArgumentNullException("site");
if (string.IsNullOrEmpty(url))
return url;
Uri originalUri = new Uri(url);
Uri translateUri = SPFarm.Local.AlternateUrlCollections
.RebaseUriWithAlternateUri(originalUri, site.Zone);
if (translateUri == null)
return url;
return translateUri.ToString();
}
Analogicky regex pro replace url odkazů v html textu.
Provozovat SharePoint 2013 na jednom stroji v defaultní konfiguraci je téměř nemožné, minimálně na stroji s 12GB operační paměti je to nepoužitelné. Jasně, pro produkci je to nesmysl a dle Microsoftu nesprávná konfigurace HW (jenže v ČR to tak veselé není, hlavně díky ceně licencí – dle mého odhadu, 60% zákazníků používá single server, u zákazníků s Foundation je to 99.99%). Můj konkrétní problém je však samozřejmě na vývojovém serveru, kde to nechci provozovat na x strojích, ale chci to mít vše all-in-one, aby se to dalo snadno zálohovat, provádět snapshoty atd.
[more]
SharePoint 2013 nepřináší z mého pohledu nic závratně nového, proč tedy spotřebovává neskutečné množství operační paměti? Protože přeci obsahuje nový fulltextový engine, který funguje téměř realtime, začíná vracet i relevantní data, ale sám o sobě spotřebuje kompletně celý server Naštěstí to lze lehce konfigurovat, není nutné to úplně vypnout, je možné upravit spotřebu paměti.
Úplné vypnutí search serveru, byť i na vývojovém serveru, nedoporučuji, search server je totiž mocný tester, leckdy lepší než ten skutečný váš kolega. Proč? Jednoduše zjistíte, že některé stránky, webparty či custom actions se renderují příliš dlouho, že někde přeleze treashold (search neběží pod adminem, který má threshold vypnutý), uvidite chyby kontextu a podobně.
A teď k tomu search enginu, i po pár minutách se aktivují nenažrané procesy “Microsoft Office 2013 component”, což není nic jiného než xkrát spuštěná služba “NodeRunner.exe”.
Detail procesu:
Po několika hodinách provozu není problém, aby tyto procesy spotřebovali 10GB operační paměti.
Nyní jak to změnit, doporučuji změnit pouze na vývojovém prostředí (ale na produkci to bude fungovat samozřejmě taky):
spusťte SharePoint PowerShell a proveďte příkaz: Set-SPEnterpriseSearchService –PerformanceLevel Reduced
pomocí poznámkového bloku najděte a otevřete soubor: C:\Program Files\Microsoft Office Servers\15.0\Search\Runtime\1.0\noderunner.exe.config
najděte element nodeRunnerSettings a memoryLimitMegabytes, nastavte hodnotu na 250 – což je limit 250 MB na jeden proces NodeRunner.exe <nodeRunnerSettings memoryLimitMegabytes=”250” />
Uložte změny, restartujte server
Budu rád za jakýkoliv feedback či případné jiné nápady, mě to pomohlo a na stroji je konečně možné i vyvíjet.