Powershell: How to batch-convert Word files to PDF

Kurz gegoogelt und, wie so oft, die Antwort bei stackoverflow gefunden:

$documents_path = 'c:\doc2pdf'

$word_app = New-Object -ComObject Word.Application

# This filter will find .doc as well as .docx documents
Get-ChildItem -Path $documents_path -Filter *.doc? | ForEach-Object {
    $document = $word_app.Documents.Open($_.FullName)
    $pdf_filename = "$($_.DirectoryName)\$($_.BaseName).pdf"
    $document.SaveAs([ref] $pdf_filename, [ref] 17)
    $document.Close()
}

$word_app.Quit()

Quelle: https://stackoverflow.com/questions/16534292/basic-powershell-batch-convert-word-docx-to-pdf

Sharepoint: How to move/copy a workflow between sites/sitecollections

Wenn die Variante „Export as Visio“ und „Import from Visio“ nicht funktioniert gibt es einen einfachen Cheat:

  • Im SPD den alten Workflow als Visio exportieren (z.B. „old“ oder „source“ an den Namen anhängen)
  • Im SPD für die (neue) Liste einen neuen Workflow erstellen, veröffentlichen und diesen ebenfalls als Visio exportieren (z.B. „new“ order „destination“ an den Namen anhängen)
  • beide exportierte Files von *.vwi zu *.vwi.zip umbenennen
  • aus dem Zip der „new“ (bzw. „destination“) Version die Datei „workflow.xoml.wfconfig.xml“ in das Zip der „old“ (bzw. „source“) Version kopieren!
    Achtung: Von „new“ nach „old“!! Nicht umgekehrt!!
  • die *.vwi.zip Dateien wieder zurückbenennen nach *.vwi
  • Im SPD in der Workflow Ansicht den Workflow markieren (nur markieren! nicht öffnen) und dann mit „Import as Visio“ die geänderte „old“ (bzw. „source“) Version erneut importieren

Fertig.

Quelle:

Bei mir in dieser Situation nicht funktionierende Quelle:

 

 

Vmware: what about vm’s outside of any resource group?

Welchen Anteil bekommen VM’s, die nicht in einer Recourse-group enthalten sind?

Die Antwort ist eigentlich recht einfach: In den „VM-Hardware“ Einstellungen einer VM kann man schön sehen welche „Anteile“ diese VM bekommt. Bei uns waren das folgende Werte:

Pro 1 vCPU    --> 1000 Shares
Pro 1 MB Ram  -->   10 Share

Damit lassen sich also die Anteile der VM’s außerhalb einer Resource-group recht einfach mit jenen einer Resource-group vergleichen.  Wenn man einer Resource-group die Anteile „Niedrig“ vergibt, dann wurden dieser Resource-groups folgende Shares zugewiesen:

CPU  -->  2000 Shares --> entspricht 2 vCPU's
Ram  --> 81920 Shares --> entspricht 8 GB Ram

Bei uns entsprach diese Resource-group also einer VM mit 2 vCPU’s und 8GB Ram.

Hilfreiche Links dazu:

http://wahlnetwork.com/2012/02/01/understanding-resource-pools-in-vmware-vsphere/
https://www.experts-exchange.com/questions/28918879/shares-on-a-VM-that-is-outside-ANY-all-resource-pool.html

 

Sharepoint: Using host-named-site-collections

Alle Infos rund um Host-named-site-collections in einem Blog-Beitrag!

What Every SharePoint Admin Needs to Know About Host Named Site Collections

In aller Kürze:  Soweit ich das verstanden habe kann man HNSC jederzeit und überall verwenden. Die ersten Limits in das man läuft sind in Zusammenhang mit der Suche.

Maximum 50 content sources per search service application.
Maximum 100 start addresses per content source.

Alle anderen Limits sind so weit „oben“ angesiedelt, dass man dort als „normaler“ Sharepoint-User oder -Admin sowieso nicht hinkommt. Sollte man an diese Grenzen stoßen, ist man schon soweit Profi, dass man diese Grenzen sowieso kennt 😉

Ein anderes Limit, an das man „recht bald“ stoßen kann ist dieses hier:

Managed path for host-named site collections: 20 per Farm
Managed path for path-based site collections: 20 per web application

Das sollte man irgendwo im Hinterkopf haben 😉

Quelle: https://technet.microsoft.com/en-us/library/cc262787(v=office.16).aspx