PowerShell-Cmdlets für Web Deploy
von Owais Shaikh
Web Deploy V3.0 wird mit PowerShell-Cmdlets bereitgestellt, mit denen Sie die meisten der von der Web Deploy API [Microsoft.Web.Deployment] unterstützten Aufgaben ausführen können. Weitere Informationen über diese API finden Sie hier. Diese Cmdlets befinden sich in dem Snapin mit dem Namen WDeploySnapin3.0, das als Snapin auf einer normalen oder höheren Installation von Web Deploy installiert und registriert ist. Um diese Cmdlets zu verwenden, fügen Sie das Snapin entweder jedes Mal hinzu, wenn die PowerShell-Konsole gestartet wird, oder Sie fügen das Snapin zum PowerShell-Profil hinzu, so dass alle Konsolen das Snapin automatisch laden.
Für das Hinzufügen beim Laden der PowerShell-Konsole führen Sie den folgenden Befehl im Konsolenfenster aus:
Add-PSSnapin WDeploySnapin3.0
Um es dem PowerShell-Profil hinzuzufügen:
- Wenn Sie bereits ein PowerShell-Profil haben, fahren Sie mit Schritt 4 fort.
- Erstellen Sie unter <Eigene Dokumente> einen WindowsPowerShell-Ordner.
- Erstellen Sie eine Datei mit dem Namen Microsoft.PowerShell_profile.ps1.
- Fügen Sie diese Zeile zur PowerShell-Profildatei hinzu: „Add-PSSnapin WDeploySnapin3.0“
Einige Punkte sind zu beachten:
- Die PowerShell-Konsole läuft in 64 Bit auf 64-Bit-Systemen und läuft in .Net 2.0, außer bis Windows 8. Wenn Sie aufgrund eines oder beider dieser Punkte Probleme haben, finden Sie Lösungen im Abschnitt Problembehandlung.
- Alle Cmdlets, die ein Web Deploy-Paket erstellen, erstellen Parameter für die gängigsten Aufgaben, und die Cmdlets, die es verwenden, akzeptieren Parameterwerte.
- Es gibt nur ein Cmdlet zum Löschen einer Website oder einer darunter liegenden App.
- Web Deploy verfügt über Parameter, aber diese sind orthogonal zu den Parametern der PowerShell-Cmdlets. Wenn in diesem Dokument von Parametern die Rede ist, sind damit Cmdlet-Parameter gemeint. Web Deploy-Parameter wurden ausdrücklich als Web Deploy-Parameter bezeichnet.
I. Veröffentlichen der Einstellungsdatei
Alle unten angegebenen Cmdlets können für ein Remoteartefakt wie einen Remoteserver oder eine Remotedatenbank ausgeführt werden. Diese erfordern mehr als nur die Anmeldeinformationen. Sie benötigen z. B. den Namen des Remoteservers, die Verbindungszeichenfolge der Remotedatenbank, ob Sie die Veröffentlichung auf einem Server mit einem Testzertifikat zulassen möchten usw. Zur Vereinfachung der Nutzung und zur Übertragung von Anmeldeinformationen vom Serveradmin zum Consumer usw. ist ein neuer Dateityp entstanden, der diese Einstellungen zusammenfasst. Diese Datei wird als Veröffentlichungseinstellungsdatei bezeichnet und besitzt die Dateiendung „.publishsettings“. Sie wird von Visual Studio sowie von WebMatrix für die Veröffentlichung verwendet.
Um eine solche Datei für den Verbrauch durch andere Cmdlets zu erstellen und sie zu bearbeiten, kann dann Cmdlet new-WDPublishSettings verwendet werden. Wenn kein Dateiname angegeben wird, wird eine neue Datei in Ihrem Dokumentverzeichnis mit dem Namen <new guid>.publishsettings erstellt. Dieser Pfad wird angezeigt, wenn die Datei erstellt wird. Wenn ein Dateiname angegeben ist und die Datei nicht vorhanden ist, wird sie wie oben im durch den Pfad angegebenen Ordner erstellt. Der Pfad zu der Datei muss jedoch gültig sein. Wenn die Datei existiert, werden nur die Werte für die Attribute, die Sie beim Ausführen des Befehls angegeben haben, geändert, mit Ausnahme der Attribute in der Datei, die unbekannt sind und diejenigen, die entfernt werden.
Beispiel: In diesem Beispiel wird ein Anmeldeinformationsobjekt abgerufen und zusammen mit anderen Parametern an das Cmdlet „new publish settings file“ übergeben
$cred = Get-Credential
New-WDPublishSettings -ComputerName owais-1 -Site Site1 -Credentials $cred -AllowUntrusted -SiteUrl "https://www.mywebsite.com" -FileName C:\pprofiles\mywebsite.publishsettings -AgentType wmsvc
Get-WDPublishSettings cmdlet allows to load values from a publish setting file into PublishSettings object.
$publishsettings=Get-WDPublishSettings C:\pprofiles\mywebsite.publishsettings
II. Backup
Alle Backup-Cmdlets haben einen Positionsparameter (es ist der zweite, außer bei „backup-wdserver“, hier ist es der erste Positionsparameter) mit dem Namen „output“. Dort wird ein Pfad zu dem Ordner angegeben, in dem das Backup erstellt werden soll. Das Backup ist immer ein Web Deploy-ZIP-Paket. Weitere Informationen zu Web Deploy-Paketen finden Sie beim Paketanbieter. Wenn kein Pfad angegeben ist, werden die Sicherungen in einem Ordner mit dem Namen „Web Deploy Backups“ im Ordner „Dokumente“ des Benutzers bzw. der Benutzerin erstellt. Die Backups werden machinename_nameofproviderused_[Siteorapporfoldername(Optional)]_timestamp.zip genannt.
Alle diese Cmdlets arbeiten standardmäßig lokal, es sei denn, Sie geben eine Datei mit Veröffentlichungseinstellungen für den Parameter SourcePublishSettings an, die Informationen zum Remoteserver enthält.
A. IIS
Alle IIS-Cmdlets funktionieren, wenn die IIS-Version 7 oder höher installiert ist.
1. Server
Backup-WDServer
Beschreibung: Erstellt ohne Argumente ein Backup des aktuellen Servers, auf dem dieser Befehl ausgeführt wird. Für diesen Vorgang wird der bekannte Webserveranbieter verwendet. Daher enthält das erstellte Paket alle Artefakte, die auch in einem Webserver-Paket enthalten wären. Weitere Informationen zu diesem Anbieter finden Sie hier.
Cmdlet-Parameter: Mit dem Parameter ConfigOnly können Sie den gesamten Inhalt ausschließen, während Sie mit den Parametern SkipFileList und SkipFolderList selektiv eine oder mehrere Dateien oder Ordner aus dem Paket ausschließen können.
Beispiele:
Dadurch wird alles vom Webserver gesichert, mit Ausnahme des folgenden Inhalts:
Backup-WDServer -SourcePublishSettings c:\profiles\myserver.publishsettings -ConfigOnly
Erstellen Sie eine Liste der Dateien, die übersprungen werden sollen. Dies sind die üblichen regulären Ausdrücke.
$list = @('\\site2\\iisstart.htm','\\site2\\welcome.png')
Backup-WDServer –SkipFileList $list
Sie können dies auch ändern, um alle Dateien unter site2 zu überspringen, indem Sie die Liste in $list=@('\site2\') ändern.
2. Website
Backup-WDSite
Beschreibung: Sichert eine IIS-Website mitsamt ihren Einstellungen und Inhalten über den apphostconfig-Anbieter. Weitere Informationen zu diesem Anbieter finden Sie hier.
Cmdlet-Parameter: Der Name der Website, der durch den Parameter site oder durch die Datei mit den Veröffentlichungseinstellungen angegeben wurde, wird gesichert. Der Wert des Parameters site überschreibt die Angabe der Veröffentlichungseinstellungen für den Namen der Website.
ConfigOnly kann verwendet werden, um ein Backup ohne Inhalt zu erstellen. Wenn die Website einen nicht standardmäßigen Anwendungspool verwendet, verwenden Sie den Switch-Parameter includeAppPool, damit dieses Paket auch auf anderen Servern funktioniert, die möglicherweise nicht denselben Anwendungspool haben. Dadurch wird der Anwendungspool in das Paket gebündelt.
Automatisch generierte Web Deploy-Parameter: Es werden zwei Arten von Parametern erstellt:
- Ein Parameter, der es dem Benutzer bzw. der Benutzerin ermöglicht, den Namen der Website zu ändern, auf die das Site-Backup angewendet werden soll.
- Ein weiterer Parameter, der es dem Benutzer bzw. der Benutzerin ermöglicht, den physischen Pfad der Website und jeder Webanwendung unter dieser Website zu ändern.
Wenn ich also eine Site mit drei Anwendungen darunter habe, erhalte ich 4 physische Pfadparameter und einen Parameter für den Website-Namen.
Beispiele:
Backup-WDSite "Default Web Site" -ConfigOnly
Backup-WDSite MySite –IncludeAppPool
Backup-WDSite MySite -SkipFileList $list
3. Webanwendung
Backup-WDApp
Beschreibung: Damit wird eine Webanwendung mit dem iisApp-Anbieter gesichert. Weitere Informationen zu diesem Anbieter finden Sie hier. Hier ist ein guter Artikel, der erklärt, was eine Webanwendung ist und was der Unterschied zwischen einer Website, einer App und einem virtuellen Verzeichnis im IIS ist.
Cmdlet-Parameter: Der Name der Anwendung, der durch den Anwendungsparameter oder durch die Datei mit den Veröffentlichungseinstellungen angegeben wurde, wird gesichert. Wenn keiner von ihnen angegeben ist, wird ein Fehler ausgegeben. Der Wert des Anwendungsparameters überschreibt die Angabe der Veröffentlichungseinstellungen für den Websitenamen. Mit den Parametern SkipFileList und SkipFolderList können Sie selektiv eine oder mehrere Dateien oder Ordner aus dem Paket ausschließen.
Automatisch generierte Web Deploy-Parameter: Während der Wiederherstellung oder Installation wird ein Parameter zum Ändern des Namens der App oder Website erstellt.
$list = @('\\iisstart\.htm')
Backup-WDApp "Default web site/app" -SkipFileList $list
B. Datenbank
1. MSSql
Backup-WDSqlDatabase
Beschreibung: Damit wird eine Microsoft SQL Server-Datenbank mit dem Anbieter dbfullsql gesichert. Dieser Anbieter verwendet SMO, um die Datenbank zu skripten, und bietet mehr als 100 Anbietereinstellungen, um die Art und Weise zu steuern, wie die Datenbank geskriptet wird. Dies wird hier ausführlich behandelt.
Cmdlet-Parameter: Die Verbindungszeichenfolge, die durch den Parameter Database oder SQLServerDBConnectionString in der Datei mit den Veröffentlichungseinstellungen festgelegt wurde, wird gesichert. Der Wert des Parameters Database überschreibt die Angabe der Veröffentlichungseinstellungen für SQLServerDBConnectionString. Die Anbietereinstellungen, die dieser Anbieter von dbfullsql bereitstellt, können mit dem Parameter SourceSettings übergeben werden. Eine sehr häufig verwendete Einstellung ist scriptdropsfirst, die bei Vorhandensein eines Objekts die Skripte des Objekts ablegt. Eine weitere Anbietereinstellung aus den SMO-Skriptoptionen ist, scriptdata auf „false“ zu setzen, um nur das Schema zu extrahieren.
Automatisch generierte Web Deploy-Parameter: Während der Wiederherstellung oder Installation wird ein Parameter zum Ändern der Verbindungszeichenfolge der Datenbank erstellt
Beispiele:
New-WDPublishSettings -ComputerName serverName -MSSqlConnectionString "Data Source=localhost;Initial Catalog=MyDb;User id=MyDbUser;Password=MyPassword" -FileName d:\SQLdb.PublishSettings -Credential serverName\Administrator
Backup-WDSQLDatabase -SourcePublishSettings D:\SQLdb.PublishSettings
Backup-WDSQLDatabase -Database "Data Source=localhost;Initial Catalog=MyDb;User id=MyDBUser;Password=MyPassword" -SourceSettings @{ copyAllUsers='false'; scriptDropsFirst='true'; }
2. MySql
Backup-WDMySQLDatabase
Beschreibung: Dadurch wird eine MySql Server-Datenbank mit dem Anbieter dbmysql gesichert. Dieser Anbieter verwendet mysqldump, um die Datenbank zu skripten. Dies wird hier ausführlich behandelt.
Cmdlet-Parameter: Die Verbindungszeichenfolge, die durch den Parameter Database oder mySQLDBConnectionString in der Datei mit den Veröffentlichungseinstellungen festgelegt wurde, wird gesichert. Der Wert des Parameters Database überschreibt die Angabe der Veröffentlichungseinstellungen für mySQLDBConnectionString. Die Anbietereinstellungen können mithilfe des Parameters SourceSettings übergeben werden. Die am häufigsten verwendeten Einstellungen sind includeData und includeSchema. Standardmäßig sind diese auf „true“ festgelegt.
Automatisch generierte Web Deploy-Parameter: Während der Wiederherstellung oder Installation wird ein Parameter zum Ändern der Verbindungszeichenfolge der Datenbank erstellt
New-WDPublishSettings -ComputerName serverName -MySqlConnectionString "Data Source=localhost;database=MyDb;Uid=MyDbUser;pwd=MyPassword" -FileName d:\MySQLdb.PublishSettings -Credential serverName\Administrator
Backup-WDMySQLDatabase -Database 'Server=localhost;Database=MyDb;Uid=MyDbUser;pwd=MyPassword’
Backup-WDMySqlDatabase –SourcePublishSettings d:\mysqldb.publishsettings
III. Wiederherstellen
Allen Wiederherstellungs-Cmdlets wird das wiederherzustellende Web Deploy-Paket als erster Positionsparameter übergeben.
Web Deploy unterstützt das Konzept der Parametrisierung der Pakete, mit dem Sie einige Aspekte während der Wiederherstellung ändern können (ohne das Paket zu verändern). Bei der Wiederherstellung können Sie beispielsweise den Wert der Verbindungszeichenfolge der Datenbank angeben, der sich von dem im Paket enthaltenen Wert unterscheidet, indem Sie Web Deploy-Parameter verwenden (der Parameter für die Verbindungszeichenfolge muss im Paket vorhanden sein).
Je nachdem, wie das Paket erstellt wurde, kann das Web Deploy-Paket einen oder mehrere Parameter enthalten. Diese Wiederherstellungs-Cmdlets prüfen das Paket und fügen der Sammlung dynamische PowerShell-Parameter hinzu. Wenn also ein Paket einen Web Deploy-Parameter mit dem Namen „Parameter1“ hat, finden Sie auch einen PowerShell-Parameter mit dem Namen „Parameter1“. Dynamische Parameter haben jedoch ihre eigenen Probleme in der PowerShell und dies funktioniert nur, wenn die Pakete kein Leerzeichen in ihrem Namen oder im Pfad zur Datei haben.
Alternativ dazu verfügen alle diese Wiederherstellungs-Cmdlets auch über einen Parameter „Parameters“, mit dem Sie während der Wiederherstellung manuell neue Parameterwerte angeben können. Dieser Parameter „Parameters“ akzeptiert ein PowerShell Dictionary-Objekt der Name-Wert-Paare der Web Deploy-Parameter.
Um herauszufinden, welche Web Deploy-Parameter in einem beliebigen Web Deploy-Paket definiert sind, öffnen Sie einfach die ZIP-Datei im Windows Explorer und untersuchen Sie die Datei parameters.xml, die sich im Stammverzeichnis des Pakets befindet. Für jeden Web Deploy-Parameter, der nicht über einen Standardwert oder einen Wert verfügt, muss ein Wert angegeben werden. Fügen Sie alle diese Parameter in eine XML-Datei ein und geben Sie diese als Wert für den Parameter ParameterValuesFile an. Sie können diese Datei wie hier angegeben oder manuell generieren. Das Format lautet
<parameters>
<setParameter name="name1" value="value1" />
<setParameter name="name2" value="value2" />
</parameters>
Das Cmdlet Get-WDParameters kann diese Datei lesen und in ein Web Deploy-Parameterobjekt (Dictionary) umwandeln, das von allen Wiederherstellungs-Cmdlets akzeptiert wird.
Wenn ein Paket wiederhergestellt wird, ohne dass ein Wert für die darin enthaltenen Parameter angegeben wird, werden standardmäßig die Ressourcen überschrieben, aus denen das Paket ursprünglich erstellt wurde. Wenn ich z. B. mit backup-wdsite site1 ein Paket von site1 erstelle und dieses Paket dann mit dem Wiederherstellungs-Cmdlet wiederherstelle, ohne den Parametern in diesem Paket Werte zuzuweisen, wird site1 mit dem gesamten Umfang des Pakets überschrieben, sowohl mit dem Inhalt als auch mit der Konfiguration. Gleiches gilt für alle Wiederherstellungs-Cmdlets.
Alle diese Cmdlets stellen die Daten lokal wieder her, es sei denn, es wird eine Datei mit den Veröffentlichungseinstellungen als Ziel angegeben. In diesem Fall würde der gleiche Vorgang über den Webverwaltungsdienst (WMSvc) oder den Web Deployment Agent-Dienst auf einem Remoteserver ausgeführt.
A. IIS
1. Server
Restore-WDServer
Beschreibung: Stellt ein Webserverpaket wieder her. In der Regel wird ein Server gesichert, bevor eine Änderung vorgenommen wird. Im Falle eines Fehlers kann der Server wiederhergestellt werden, indem das vor der Änderung erstellte Web Deploy-Backup-Paket angewendet wird.
$folderList = @(‘\\app_data’)
Restore-WDServer D:\OWAIS-1_WebServer_20120419121214.zip -DestinationPublishSettings c:\destinationServer.publishSettings –SkipFolderList $folderList
2. Website
Restore-WDSite
Beschreibung: Stellt ein IIS-Websitepaket wieder her. Wenn das Paket zwei Parameter mit den Namen „Site Physical Path“ und „Site Name“ hat, werden diese als dynamische Powershell-Parameter SitePhysicalPath und SiteName angezeigt. Dieser Befehl erstellt eine neue Website site1 mit dem physischen Pfad c:\site1. Wenn für diese Parameter kein Wert angegeben wird, wird die Wiederherstellung auf dieselbe Website und denselben Inhalt angewendet und überschreibt alle Änderungen, die Sie an der Website vorgenommen haben.
Parameter: Sie können skipfolderlist und skipfilelist verwenden, um bestimmte Ordner und/oder Dateien vom Kopieren der Website-Inhalte auszuschließen.
Restore-WDSite C:\defaultsite.zip -SitePhysicalPath c:\site1 -SiteName site1
Restore-WDSite -Package 'D:\Users\Administrator\Documents\Web Deploy Backups\IIS-Server_AppHostConfig_Default Web Site_20120417100827.zip' -skipFolderList @('App_Data') -verbose
3. App
Restore-WDApp
Beschreibung: Dadurch wird eine Webanwendung wiederhergestellt. Backup-WDApp erstellt ein Paket mit einem Parameter, um den Namen der App bei der Installation zu ändern. Dies kann verwendet werden, um die App während der Wiederherstellung in eine andere App wiederherzustellen. Die Website muss bei der Bereitstellung einer App unter einer Website vorhanden sein. Die App wird von diesem Paket erstellt, aber die Website wird nicht erstellt.
Beispiele:
Restore-WDApp C:\myappbackup.zip -ApplicationPathParam1 "Default web site\app1"
B. Datenbank
Restore-WDDatabase
Beschreibung: Wenn die Datenbank nicht existiert, wird eine neue Datenbank mit dem Namen „Kunden“ erstellt (sofern der aktuelle Benutzer bzw. die aktuelle Benutzerin die Berechtigung für diesen Vorgang hat) und das Skript auf dieser Datenbank ausgeführt. Wenn dies ohne Werte für dynamische Web Deploy-Parameter ausgeführt wird, wird die ursprüngliche Datenbank, aus der dieses Paket erstellt wurde, überschrieben. Beachten Sie, dass die Anwendung auf eine Datenbank mit widersprüchlichen vorhandenen Inhalten fehlschlägt, wenn bei der Erstellung des Pakets die Einstellung scriptDropsFirst nicht verwendet wurde. Mit diesem Cmdlet können Sie entweder ein MSSql- oder ein MySQL-Backup wiederherstellen. Sie können eine MS SQL-Datenbank nur mit einem Backup wiederherstellen, das mit Backup-WDSQLDatabase erstellt wurde, und eine My SQL-Datenbank nur mit einem Backup, das mit Backup-WDMySqlDatabase erstellt wurde.
Beispiele:
Backup-WDSqlDatabase "server=.\sqlexpress;integrated security=SSPI;database=customers" "C:\dbbackup.zip"
Restore-WDDatabase c:\dbbackup.zip –DatabaseConnectionStringParam1 "server=.\sqlexpress;integrated security=SSPI;database=customers_copy"
Backup-WDMySqlDatabase "server=localhost;uid=someuser;pwd=somepwd;database=coolDb" "C:\dbbackup.zip"
Restore-WDDatabase c:\dbbackup.zip –DatabaseConnectionStringParam1 "server=localhost;uid=someuser;pwd=somepwd;database=coolDb_copy"
C. Generisches Paket
Restore-WDPackage
Beschreibung: Dieses Cmdlet kann verwendet werden, um ein beliebiges Web Deploy-Paket anzuwenden. Es gibt mehrere Möglichkeiten, ein Web Deploy-Paket zu erstellen oder zu erhalten, z. B. durch Herunterladen eines Open-Source Application Gallery-Pakets, durch Erstellen eines Pakets in Visual Studio, mit dem Befehlszeilen-Tool msdeploy.exe (weitere Informationen) oder mit den weiter oben im Dokument beschriebenen Backup-WD*-Cmdlets. Um z. B. Wordpress auf einer IIS Server Standardwebsite als App namens Wordpress zu installieren, laden Sie das Wordpress-Paket aus dem App-Katalog in einen Ordner mit dem Namen „packages“ herunter. Alle Standardwerte für die Parameter des Wordpress-Pakets funktionieren problemlos, Sie müssen lediglich die Werte für zwei erforderliche Parameter angeben: die mysql-Kennwörter für Admin und Nicht-Admin.
Parameter:
Restore-WDPackage c:\Packages\wordpress.zip -DBAdminPassword mysecretserverpassword –DBPassword mysqllocalpassword
IV. Remove (Entfernen)
Remove-WDSite -Site NonWorkingSite
Dieser Befehl löscht die Definition der Website mit dem Namen nonworkingsite in der Datei applicationHost.config sowie den Inhalt des Verzeichnisses der Website.
V. Abrufen und Festlegen des App-Poolframeworks
Mit diesen Cmdlets können Sie die .Net-Framework-Version von apppool lesen und ändern.
Get-WDAppPoolFx "default web site"
managedRuntimeVersion
---------------------
v2.0
Set-WDAppPoolFx "default web site" -AppPoolFrameworkVersion v4.0
Get-WDAppPoolFx "default web site"
managedRuntimeVersion
---------------------
v4.0
VI. Festlegen von WDACL
Dieses Cmdlet kann zum Festlegen von acls für den Inhalt einer Website verwendet werden. Angenommen, ich habe eine Website, site1 und ich versuche, dem Benutzer u1 Lesezugriff zu gewähren.
Zuerst prüfe ich die aktuellen Berechtigungen.
$ret = Get-Acl C:\site1
$ret.Access
I don’t see u1 in the list. Let me give the user u1 access as follows
Set-WDAcl "site1" -SetAclUser u1
Check whether this worked
$ret = Get-Acl C:\site1
$ret.Access
I see that u1 has been given read access as below. [I have not pasted the other permissions on this folder. Just the u1 part]
FileSystemRights : Read, Synchronize
AccessControlType : Allow
IdentityReference : MOSHAIKH1\u1
IsInherited : False
InheritanceFlags : ContainerInherit, ObjectInherit
PropagationFlags : None
VII. Invoke
Sie können mit „destinationpublishsettings“ Befehle oder Skripte auf einem entfernten System aufrufen und die Ergebnisse der Remoteausführung in Echtzeit sehen. Sie benötigen auf dem Remotesystem Administratorrechte, um den Anbieter runcommand remote ausführen zu können. Weitere Informationen zu diesem Anbieter finden Sie hier. Die MWD Api wartet standardmäßig maximal 5 Sekunden, bis das angegebene Skript oder der Befehl beendet ist. Wenn Sie diese Ausführungszeit verlängern möchten, können Sie höhere Werte für waitInterval und waitAttempts angeben, wie im folgenden Beispiel gezeigt.
A. Skript
Invoke-WDScript C:\my.cmd –Verbose
Dadurch wird das Skript ausgeführt und Sie können die Ausgabe des Befehls sehen, wenn Sie ihn mit „verbose“ ausführen.
B. Get-Help
$settings = @ { waitInterval = 3000; waitAttempts = 25;}
Invoke-WDCommand "dir c:\mydirectory /s/b" -DestinationSettings $settings
Dies führt den Befehl aus und es wird keine Ausgabe angezeigt, da „verbose“ nicht angegeben wurde. Dabei wird jedoch zwischen jedem Zeitablauf 3 Sekunden gewartet und es werden 25 Iterationen von Wartezeiten durchgeführt. Insgesamt wird der Prozess höchstens 75 Sekunden lang ausgeführt.
VIII. Sync
Diese Cmdlets akzeptieren eine Quelle und ein Ziel und synchronisieren zwischen diesen beiden. Die Quelle wird nie geändert. Der Grund, warum ich das Wort „Quelle“ statt „Client“ verwende, ist, dass die Begriffe „Client“ und „Server“ bei der Synchronisierung sehr verwirrend sind. Sie synchronisieren möglicherweise einen lokalen Server mit einem Remoteserver. In diesem Fall ist der Remoteserver die Quelle und der lokale Server das Ziel. Alternativ können Sie das PowerShell-Cmdlet auf Computer 1 ausführen und die Computer 2 und 3 synchronisieren. Um eine Remotequelle und/oder ein Remoteziel zu verwenden, müssen Sie eine Datei mit Veröffentlichungseinstellungen bereitstellen, die mit dem ersten in diesem Dokument erwähnten Cmdlet erstellt werden kann. Alle Cmdlets für die Synchronisierung unterstützen auch die Parameter sourceSettings und destinationSettings, mit denen Sie Anbietereinstellungen für die Quelle, das Ziel oder beide festlegen können.
A. IIS
1. Server
Ich möchte zwei IIS 7.5-Server, Owais-1 und Owais-2 synchronisieren. Ich werde zunächst für jeden eine publishsettings-Datei erstellen und dann die Server synchronisieren. Da ich meine Anmeldedaten nicht angegeben habe, wird dies gelingen, wenn ich administrative Rechte für diese beiden Systeme habe.
New-WDPublishSettings -ComputerName owais-1 -AgentType MSDepSvc -FileName c:\owais1.publishsettings
Publish settings file created at: 'c:\owais1.publishsettings'.
New-WDPublishSettings -ComputerName owais-2 -AgentType MSDepSvc -FileName c:\owais2.publishsettings
Publish settings file created at: 'c:\owais2.publishsettings'.
Sync-WDServer -SourcePublishSettings c:\owais1.publishSettings -DestinationPublishSettings c:\owais2.publishSettings
2. Website
Im folgenden Befehl wird site2 erstellt, wenn sie noch nicht existierte, und ich habe auch den physischen Pfad (der Inhalt wird also in den neuen Ordner c:\site2 kopiert) und die Bindung der Website geändert.
Sync-WDSite site1 Site2 -SitePhysicalPath c:\site2 -SiteBinding "*:8078:" -IncludeAppPool
3. App
Ich habe eine Anwendung, die unter der Standardwebsite ausgeführt wird. Ich möchte diese unter „Site1“ verschieben. Der folgende Befehl führt dies aus.
Sync-WDApp "Default Web Site/drupal" "site1/drupal"
Nachdem ich nun getestet habe, dass meine neue Drupal-App funktioniert, werde ich die ursprüngliche Drupal-App unter der Standardwebsite löschen.
Remove-WDSite "Default Web Site/drupal"
B. Datenbank
Die bisher beschriebenen Cmdlets haben gezeigt, wie Sie eine Datenbank mithilfe eines Web Deploy-Pakets sichern und wiederherstellen können. Sie können jedoch auch eine Datenbank mit einem .sql-Skript synchronisieren oder direkt mit einer anderen Datenbankinstanz synchronisieren, indem Sie die Cmdlets Sync-WDSQLDatabase und Sync-WDMySQLDatabase verwenden.
1. MSSql
Sync-WDSQLDatabase "server=.\sqlexpress;uid=sa;pwd=********;database=umbracodb" "server=.\sqlexpress;uid=sa;pwd=************;database=sometestdb"
Dadurch wird eine neue Datenbank mit dem Namen sometestdb erstellt (falls sie noch nicht existiert) und Schema und Daten werden synchronisiert.
Sync-"server=.\sqlexpress;uid=sa;pwd=********;database=umbracodb" c:\umbraco.sql
Dadurch wird die Datenbank umbracodb in umbraco.sql unter dem oben angegebenen Pfad ausgelesen.
2. MySql
Sync-WDMySQLDatabase "server=localhost;uid=root;pwd=********;database=wordpress265" "server=localhost;uid=root;pwd=************;database=wordpress265_new"
Dadurch wird eine neue Datenbank mit dem Namen wordpress265_new erstellt (falls sie noch nicht existiert) und Schema und Daten werden synchronisiert.
Sync-WDMySQLDatabase "server=localhost;uid=root;pwd=***************;database=wordpress265" c:\wordpress.sql
Dadurch wird die Datenbank wordpress265 in wordpress.sql unter dem oben angegebenen Pfad ausgelesen.
C. Alle anderen
Für die allgemeine Synchronisierung, die von den anderen oben genannten Cmdlets nicht abgedeckt wird, können Sie das Cmdlet Sync-WDManifest verwenden. Dies ist eine allgemeine Manifestanbietersynchronisierung, die von der MWD-API unterstützt wird. Weitere Informationen dazu finden Sie hier. Manifest ist eine Sammlung von Anbietern, Anbieterpfaden und Anbietereinstellungen in einer XML-Datei. Es ist so aufgebaut, dass der Stammknoten der XML-Datei als Name eines Anbieters für den Zweck der aktuellen Synchronisierung betrachtet wird. Daher kann es nicht der Name eines der bekannten Anbieter sein, die in der Liste hier angegeben sind. Außerdem kann es untergeordnete Knoten haben, deren Elementname dem Anbieter entspricht, den Sie in die Synchronisierung einbeziehen möchten. Ein Pfad-Attribut stellt den Pfad dieses Anbieters dar und ist obligatorisch. Fügen Sie dann Attributwertpaare für jede Anbietereinstellung hinzu, die Sie für den aktuellen Synchronisierungsvorgang nutzen möchten.
Dieses Cmdlet benötigt zwei Manifeste: eins für die Quelle und eins für das Ziel. Das Manifest wird immer in der angegebenen Reihenfolge ausgeführt. Wenn der Anbieter einen Commit-Vorgang unterstützt, wie z. B. der Anbieter apphostconfig, der mit IIS Sites arbeitet, wird der Commit-Vorgang erst aufgerufen, wenn die Synchronisierung abgeschlossen ist. Wenn Sie also zuerst einen Anbieter angeben, der erwartet, dass eine Website existiert, und erst danach einen Anbieter, der sie erstellt, dann wird dies fehlschlagen, da die Website noch nicht committed wurde. Im folgenden Beispiel werde ich eine App synchronisieren und eine Datenbank, die die App verwendet, mit in das Manifest aufnehmen.
Quellmanifest:
<demoManifest>
<iisApp path="Site1" />
<dbfullsql path="server=.\sqlexpress;integrated security=SSPI;database=customers" />
</demoManifest>
Zielmanifest:
<demoManifest> <iisApp path="Site2" /> <dbfullsql path="server=.\sqlexpress;integrated security=SSPI;database=customers_demo_cpy" /></demoManifest>Sync-WDManifest C:\sourceManifest.xml C:\destManifest.xmlWARNING: Cannot connect to the database 'customers_demo_cpy'.Retrying operation 'Add' on object dbFullSql (server=.\sqlexpress;uid=sa;database=customers_demo_cpy). Attempt 1 of 5.Manifest : C:\sourceManifest.xmlManifest-Dest : C:\destManifest.xmlTimeTaken : 0:10Errors : 0Warnings : 0BytesCopied : 0ObjectsDeleted : 0ObjectsUpdated : 0ObjectsAdded : 3TotalChanges : 3ParameterChanges : 0
Feedback
Bald verfügbar: Im Laufe des Jahres 2024 werden wir GitHub-Issues stufenweise als Feedbackmechanismus für Inhalte abbauen und durch ein neues Feedbacksystem ersetzen. Weitere Informationen finden Sie unter https://aka.ms/ContentUserFeedback.
Feedback senden und anzeigen für