Vývoj vlastního CmdLetu v C# – příprava projektu Visual Studia

Vývoj vlastního PowerShell příkazu (CmdLet) je velice snadné a rychlé – ideální pro často opakované akce, případně akce u zákazníka, kde nemusí být vždy vzdálený přístup do jeho infrastruktury. Za posledních pár let už jsem jich napsal desítky a jsem jsem z toho stále nadšen, hlavně tou jednoduchostí, v podstatě jsem tím zcela nahradil jednoúčelové konzolové aplikace, kde již navíc není nutné řešit parsování argumentů, přehledná výpis na konzolovou obrazovku, všechno je již tak nějak vyřešeno. Jako příklad jednoho z CmdLetů bych uvedl snadné nasazení jedné naší aplikace hostované v Azure, kde s každým zákazníkem bylo vždy nutné přihlásit se na portál Azure, vytvořit hosting pro aplikaci, nastavit domény, standard mód, vytvořit a nastavit DB, connection string do aplikace, vytvořit storage provider, přihlašovací údaje zapsat do aplikace, nastavit zálohování, a tak bych mohl pokračovat….. až po finální nahrání zkompilované verze – prostě práce na minimálně 2-4h a to ještě s rizikem chyby. Nyní k tomu slouží dva CmdLety, jeden pro přihlášení k Azure, druhý už pro založení tenantu a provedení všech potřebných akcí zcela automaticky.

V tomto prvním díle ukážu pouze základ, založení Visual Studio projektu a jeho nastavení.

Základem vlastního PowerShell CmdLetu je založený projekt typu Class Library

image 

image

Volba verze .NET Frameworku je závislá na požadované verzi PowerShellu, pokud například skriptujete akce pro SharePoint 2010, musíte nastavit .NET Framework verze maximálně 3.5.

  • PowerShell 2.0 – .NET Framework 3.5
  • PowerShell 3.0 – .NET Framework 4
  • PowerShell 4.0 – .NET Framework 4.5
[more]

Po založení projektu je nutné ručně přidat potřebné reference, hlavní referencí je System.Management.Automation.dll, kterou naleznete (případně dle vaší verze PowerShellu):
C:\Program Files (x86)\Reference Assemblies\Microsoft\WindowsPowerShell\3.0

image

Následně se již můžeme vrhnout na prvním CmdLet, pro první sample klasicky Hello World, založíme novou třídu a pojmenujeme jí GetHelloWorldMessage:

image

A začneme přidávat atributy a base třídu:

  • importujte namespace System.Management.Automation
  • třída GetHelloWorldMessage musí být zděděna z objektu PSCmdlet
  • přidejte atribut CmdLet k nově vytvořené třídě, první parametr definuje jednu z povolených akcí, respektive prefixů (na funkci samotného CmdLetu nemá vliv, jenom definuje standard) a druhý parametr určující název samotné Powershell funkce, tentokrát bez prefixu již daného výčtovým typem VerbsCommon, výsledek tedy může být:
    [Cmdlet(VerbsCommon.Get, „HelloWorldMessage“)]
    Samotný příkaz tedy bude dostupný jako Get-HelloWorldMessage

Samotnou funkčnost implementujete přetížením metody ProcessRecord(), která je definována v base PSCmdLetu a navíc přidáme jeden vstupní parametr pro specifikaci jména uživatele – tento parametr je označen jako povinný.

image

 

using System;
using System.Collections.Generic;
using System.Linq;
using System.Management.Automation;
using System.Text;
using System.Threading.Tasks;

namespace DevIT.PowerShell.Samples
{
    [Cmdlet(VerbsCommon.Get, "HelloWorldMessage")]
    public class GetHelloWorldMessage : PSCmdlet
    {
        [Parameter(Mandatory = true, HelpMessage = "Zadejte Vaše jméno.")]
        public string YourName { get; set; }
        protected override void ProcessRecord()
        {
            WriteVerbose("Spouštíme hrozně složitou akci...");
            WriteObject(string.Format("Vítejte, {0}!", YourName ?? string.Empty));
        }
    }
}

 

Nyní už jenom zkompilujeme, spustíme konzoli PowerShellu, nalistujeme adresář s výsledným DLL souborem a importujeme ho do sady dostupných PowerShell příkazů:

Import-Module .\DevIT.PowerShell.Samples.dll

Následně již můžeme zavolat příkaz Get-HelloWorldMessage:

image

Případně rovnou s parametrem Get-HelloWorldMessage -YourName “Pavel”

Nebo klasicky parametrem –? zobrazit dostupné volby, při prvním volání nápovědy však budete vyzván k přegenerování nápovědy, která se generuje na základě atributů uvedených u CmdLetu i samotných parametrů:

image

Dynamics CRM 2013: vytvoření PDF z reportu a přiložení jako přílohy

Na MSDN webu se objevil postup formou javascriptu, jak automatizovaně vygenerovat přílohu PDF z reportu a uložit jí jako přílohu k nějaké entitě, to se samozřejmě může hodit například při generování objednávky nebo faktury z CRM a automatizovanému uložení výsledného PDF soboru k nově vytvořenému odchozímu mailu, tedy bez nutnosti krkolomného postupu: otevřít report, vygenerovat, uložit na plochu PDF, založit email, připojit přílohu….

[more]

Postup:

http://blogs.msdn.com/b/emeadcrmsupport/archive/2014/06/19/dynamics-crm-2013-custom-code-creating-a-report-as-a-pdf-attachment.aspx

 

Řešení však není všeho spásné, tím, že se jedná o javascript, nelze to automatizovat formou workflow, ale akci musí vyvolat uživatel z formuláře.

 

Já mám připravenou trošku lepší verzi Veselý obličej a to formou workflow aktivity, kterou je možné jednoduše přidat do jakéhokoliv workflow nad jakoukoliv entity, vybrat jaký report se má vygenerovat a kam ho připojit – je tedy možné akce automatizovat kompletně, například generovat automatické opakované faktury a zasílat je zákazníkům mailem ve formě PDF, brzo napíšu na blog příspěvek s ukázkou. Pokud by jste měli zájem, ozvěte se mi na email.

SharePoint: Unable to display this Web Part / System.StackOverflowException: Operation caused a stack overflow

Pokud SharePoint na nějakém webu zobrazuje místo obsahu webparty následující hlášku:

Unable to display this Web Part. To troubleshoot the problem, open this Web page in a Microsoft SharePoint Foundation-compatible HTML editor such as Microsoft SharePoint Designer. If the problem persists, contact your Web server administrator

 [more]

a v ULS logu je výjimka:

Error while executing web part: System.StackOverflowException: Operation caused a stack overflow.
at Microsoft.Xslt.NativeMethod.CheckForSufficientStack()
at SyncToNavigator(XPathNavigator , XPathNavigator )
at (XmlQueryRuntime , IList`1 , Double , XPathNavigator )
at (XmlQueryRuntime , XPathNavigator )
at Root(XmlQueryRuntime )
at System.Xml.Xsl.XmlILCommand.Execute(Object defaultDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter writer, Boolean closeWriter)
at System.Xml.Xsl.XmlILCommand.Execute(IXPathNavigable contextDocument, XmlResolver dataSources, XsltArgumentList argumentList, XmlWriter results)
at System.Xml.Xsl.XslCompiledTransform.Transform(IXPathNavigable input, XsltArgumentList arguments, XmlWriter results)
at Microsoft.SharePoint.WebPartPages.DataFormWebPart.ExecuteTransform(XslCompiledTransform xslCompiledTransform, XsltArgumentList xmlArguments, Boolean bDeferExecuteTransform)
at Microsoft.SharePoint.WebPartPages.DataFormWebPart.PrepareAndPerformTransform(Boolean bDeferExecuteTransform)

 

Zpracování XSLT trvalo déle než nakonfigurovaná maximální doba, defaultně je pouze 1 sekunda, což na SharePoint s velkým množstvím dat není mnoho Obličej s očima v sloup

PowerShellem je potřebu upravit timeout (počet sekund) maximální délky zpracování XSLT transformací:

$farm = Get-SPFarm
$farm.XsltTransformTimeOut = 5
$farm.Update()

 

a restartovat IIS příkazem IISRESET.EXE

SharePoint–řešení problémů s alerty (emailovou notifikací)

SharePoint má standardně zapnutý limit počtu alertů na jednoho uživatele, tedy kolik si jich maximálně může sám aktivovat – defaultně je toto číslo nastaveno na 500. Počet se sice zdá na jednu stranu rozumný a skoro uživatelsky nemožné, aby si někdo tolik upozornění aktivoval, ale v praxi je u některých agend málo. Příkladem mohou být například interní objednávky, kdy každá interní objednávka má definovaného řešitele pomocí kategorie (kategorii “IT” řeší IT oddělení, správu vozů administrativa, opravy strojů oddělení správy majetku, atd.), to ale znamená, že nechceme notifikovat všechny lidi, kteří mohou objednávky spravovat, tedy řešitele, ale jenom ty, kterých se daná kategorie objednávky týká – k tomu svádí vytvořit programově event receivery po vytvoření objednávky a pro dané uživatele vytvářet programově alerty na změnu položky… Ale tedy u je kámen úrazu, kdy i poměrně malá společnost je schopna vygenerovat více než 500 objednávek na jednoho uživatele, nehledě na to, že limit 500 alertů na uživatele je přes celou webovou aplikaci, kde může být více podobných agend. Vytváření alertů na jednotlivé položky tedy není z dlouhodobého pohledu dobrá cesta, ale pokud už takový nástroj/doplněk máte, nejjednodušší cestou je zvýšení limitu.

 [more]

Zvýšení limitu počtu alertů na uživatele nelze provést v UI, lze pouze příkazovou řádkou:

STSADM.EXE -o setproperty -url http://intranet.devit.cz -pn alerts-maximum -pv 10000

Pokud naopak chcete zjistit aktuálně nastavenou hodnotu, použijte:

STSADM.EXE -o getproperty -url http://intranet.devit.cz -pn alerts-maximum

 

Aktivované alerty jsou uložení v obsahové databázi, pro vypsání všech aktivních “okamžitých” notifikací lze použít SQL dotaz:

select * from [dbo].[ImmedSubscriptions] (nolock)

Případně přímo filtrovat na uživatele dle emailové adresy:

select * from [dbo].[ImmedSubscriptions] (nolock) where UserEmail = ‚novotny@devit.cz‘

SNAGHTMLf208ff

 

Analogicky lze dohledat i aktivní plánované alerty, tedy tzv. souhrnné denní nebo týdenní:

select * from [dbo].[SchedSubscriptions] (nolock)

Dynamics CRM–nová aktualizace přinese podporu SLA v servisním modulu

Pár novinek z připravované aktualizace Dynamics CRM – servisní modul:

  • Podpora SLA (Service Level Agreement) v servisním modulu a definice pravidel a priorit:
    image

[more]

image

  • Pole pro odpočítávání/počítání doby skutečně stráveného času servisního zásahu:
    image
  • Kontrola úrovně supportní smlouvy (zbývajícího počtu servisních hodin)
    image
  • Slučování duplicitních servisních případů:
    image
  • Samozřejmostí jsou statistiky pro sledování stavu ticketů, ale i doby řešení jednotlivých ticketů, doby od založení ticketu do jeho vyřešení, zdroje ticketů (Email, Web, Telefon, Twitter, Facebook)
    image

    image

  • Automatická eskalace pokud se například doba řešení blíží maximální době pro danou prioritu ticketu
    image

 

Video:

Více:

http://blogs.msdn.com/b/crm/archive/2014/06/04/3-ways-to-learn-what-s-new-with-customer-service-in-microsoft-dynamics-crm-spring-14.aspx

SPFastDeploy–rozšíření do Visual Studia pro vývoj SP Online

Do nadpisu jsem původně chtěl vložit ještě trefný suffix “pro prodloužení psychického zdraví vývojáře”, protože tento doplněk ve spoustě případů skutečně šetří nervy při deploy změn a testování – kdo nikdy nevyvíjel nic pro SharePoint, nemůže pochopit Obličej s očima v sloup Zatím ale nemám pořádně vyzkoušeno, zdá se to ale slibné.

Dostupné přímo z VS:

image

 

Lze aktivovat i mód automatického deploye po uložení:

SNAGHTML15366872

 

VS doplněk je dostupný buď přímo ze správy Extensions  Visual Studia nebo ke stažení zde:

http://visualstudiogallery.msdn.microsoft.com/9e03d0f5-f931-4125-a5d1-7c1529554fbd

Zjištění zapomenutého hesla aplikačního poolu IIS

V SharePointu 2007 byla v objektu SPApplicationPool vlastnost Password, od verze 2010 je však již označená jako deprecated, heslo se však zpětně dá zjistit příkazem z command line:

 

cmd.exe /c $env:windir\system32\inetsrv\appcmd.exe list apppool „apppoolname“ /text:ProcessModel.Password

 

Stále tedy platí, nezadávejte nikdy a nikde 2x stejné heslo, nikdy nevíte, kdy a kdo ho je schopen přečíst.

 

Zdroj: http://blah.winsmarts.com/2014-5-Find_an_Application_Pool-and-rsquo;s_password.aspx

SharePoint 2013–nasazení farm solution pro SP2013 v compatibility módu 2010

SharePoint 2013 v kolekcích webů vytvořených nebo migrovaných v compatibility módu 2010, automaticky skrývá všechny features z WSP farm řešení pro verzi 2013. Pokud tedy provádíte upgrade, připojíte starou kolekci webů 2010, nainstalujete nové farm balíčky pro podporu SP2013 a chcete ponechat kolekci ve vzhledu 2010, alespoň do dokončení nutných úprav, feature z nových balíčků neuvidíte. Aby bylo možné aktivovat nové feature na starém UI, je potřeba provést retract balíčku ze všech webových aplikací a znovu provést deploy s atributem CompatibilityLevel:

[more]

Add-SPSolution „c:\DEV\DevIT.SharePoint.FBASuite\DEV2013-SQL\Builds\DevIT.SharePoint.FBASuite.wsp“
Install-SPSolution -Identity DevIT.SharePoint.FBASuite.wsp -WebApplication http://srvdev:555 -GACDeployment CompatibilityLevel {14,15}

 

Tím dojde k automatickému zkopírování všech potřebných souborů z WSP do obou klíčových složek SharePointu:

Pro verzi 2013:

c:\Program Files\Common Files\microsoft shared\Web Server Extensions\15\TEMPLATE\FEATURES\

Pro verzi 2010:

c:\Program Files\Common Files\microsoft shared\Web Server Extensions\14\TEMPLATE\FEATURES\

 

Nyní je feature viditelná i v kolekci webů UI verze 2010.

SharePoint domény k prodeji: sharepoint-extranet.com + sharepoint-forms-authentication.com

Aktuálně nabízím k prodeji dvě domény s SharePoint tématikou, které už dosloužily svým původním účelům:

 

  1. sharepoint-extranet.com
  2. sharepoint-forms-authentication.com

 

Pokud budete mít kdokoliv zájem, neváhejte mě kontaktovat na emailu novotny@pavelnovotny.info

Vyvolávací cena je pouze 1.000 EUR / doména.