Archiv für die Kategorie ‘System Management’

Instabile VPN-Verbindung zwischen Microsoft Azure und Vyatta

Dienstag, 20. Januar 2015

17659406_blogWir haben bereits in einem Blogbeitrag erwähnt, wie ein Site-To-Site VPN-Tunnel in Azure am Beispiel eines Vyatta-Routers aufgebaut werden kann. Kürzlich wollten wir den Tunnel für ein anderes virtuelles Netzwerk in Azure aufbauen und sind dabei auf folgendes Problem gestoßen: die Verbindung war instabil. Sie brach nach bestimmten Zeitintervallen immer wieder ab. Das Problem ist uns nicht sofort aufgefallen, da die Daten größtenteils erfolgreich übertragen werden konnten.

Zwar antworteten die virtuelle Maschinen in Azure auf Ping sowie zudem die Remote Desktop Verbindung realtiv gut funktionierte, dennoch scheiterte die Synchronisierung des Domain Controllers in Azure. Nun haben wir uns auf die Fehlersuche begeben. Vyatta (bzw. VyOS) setzt Openswan für den Aufbau des IPsec-Tunnels ein. Um das Logging für einen bestehenden IPsec-Tunnel in Vyatta einzuschalten, kann beispielsweise folgende Befehlsfolge verwendet werden:

$ configure
# set vpn ipsec logging log-modes all
# commit && save && exit

Um die produzierten Logs zu lesen, muss folgender Befehl eingegeben werden:

$ show vpn debug detail

In dem Log ist uns aufgefallen, dass dort ab und zu ein Eintrag steht:

pluto[26353]: "peer-123.45.67.89-tunnel-4" #9298: max number of retransmissions (2) 
reached STATE_MAIN_R1
(123.45.67.89 ist die Adresse des Gateways in Azure)

Der Fehler verweist darauf, dass der Router Anfragen an das Azure-Gateway sendet, aber die Antwort ausfällt. Lange haben wir nach Lösungen gesucht: Weder Wiederaufbau des Tunnels, noch Anbieterwechsel, noch Reboot des Routers konnten uns helfen. Letzlich haben wir den Gateway in Azure gelöscht, neuerstellt, den Tunnel aufgebaut und (oh Wunder!) es ging sofort ohne seltsame Abbrüche.

Man kann es kaum glauen, aber in Azure können durchaus technische Probleme entstehen und diese dürfen auf keinem Fall komplett ausgeschlossen werden. Sollten Sie auf ähnliche Probleme stoßen, so können Sie uns jederzeit kontaktieren.

Während der Fehlersuche haben wir den Tunnel oft neuaufgebaut: Um den Vorgang zu beschleunigen, haben wir ein kleines Skript für Vyatta geschrieben, welches in wenigen Sekunden den Tunnel erstellt. Als Bonus für die Leser möchte ich das Skript hier veröffentlichen:

#!/bin/vbash
#Gateway IP's
azure_gateway_ip="123.45.67.89"
local_gateway_ip="98.76.54.43"

 

#Key muss beim Gateway in Azure abgelesen werden

azure_pre_shared_secret="presharedkeyfromazure"

 

#Networks

azure_net="10.10.20.0/24"
local_net="10.10.10.0/24"

 

#Change in Vyatta-Mode

source /opt/vyatta/etc/functions/script-template

 

#Configure

echo "In Configure-Mode beigetretten"
echo "Eine site-to-site VPN-Verbindung zwischen ${azure_gateway_ip} und
{$local_gateway_ip} wird aufgebaut..."
set vpn ipsec site-to-site peer $azure_gateway_ip
set vpn ipsec site-to-site peer $azure_gateway_ip description 'Azure-VPN'
set vpn ipsec site-to-site peer $azure_gateway_ip connection-type respond

#IKE&ESP-Groups sollten bereits bestehen

set vpn ipsec site-to-site peer $azure_gateway_ip default-esp-group esp-azure
set vpn ipsec site-to-site peer $azure_gateway_ip ike-group ike-azure
set vpn ipsec site-to-site peer $azure_gateway_ip local-address $local_gateway_ip
set vpn ipsec site-to-site peer $azure_gateway_ip authentication pre-shared-secret
$azure_pre_shared_secret

 

#Tunnels einrichten

set vpn ipsec site-to-site peer $azure_gateway_ip tunnel 1 local prefix $local_net
set vpn ipsec site-to-site peer $azure_gateway_ip tunnel 1 remote prefix $azure_net

 

#Aenderungen speichern

commit
save
echo "Verlasse configuration-mode..."
exit
echo "Fertig..."

Um das Skript auf der Vyatta ausführen zu können, brauchen Sie die Rechte zum Ausführen von chmode +x script.sh.

Ähnlicher Blogartikel: Windows Azure mit VPN (Vyatta) verbinden

Autor: Walter Nuss

PT_Blog_VK_WNuss_jpg

Erstellen einer (hochverfügbaren) SharePoint 2013 Farm in 30min mit Microsoft Azure

Mittwoch, 22. Oktober 2014

schnell Sharepoint in azure ausrollenMit den Azure-Diensten kann nun eine Microsoft SharePoint 2013-Farm mit SQL Server AlwaysOn bereitgestellt und betrieben werden; heißt Azure unterstützt mit den Sharepoint Server-Farm Features nun das automatische Erstellen einer vorkonfigurierten Sharepoint Server 2013-Farm. So sparen Sie jede Menge Zeit, wenn Sie eine Basis- oder hochverfügbare Sharepoint -Farm zu Test-, Entwicklungs- oder Live-Zweken benötigen. Ihre 30 Tage Azure-Testversion erhalten Sie hier.

Aus 30 Tagen werden 30 Min. – Anna, Systemadmin, zeigt Ihnen, wie schnell die SharePoint Farm steht?

Die Basis-SharePoint -Farm besteht aus drei virtuellen Maschinen:
SharePoint Farm Basiskonfiguration

SharePoint Farm Basiskonfiguration

Sie können diese Farm-Konfiguration bspw. für eine SharePoint-App-Entwicklung oder für Ihre erstmalige Evaluierung von Sharepoint 2013 verwenden.

Die hochverfügbare SharePoint-Farm besteht aus neun virtuellen Maschinen:
SharePoint Farm Hochverfügbarkeitskonfiguration

SharePoint Farm Hochverfügbarkeitskonfiguration

Sie können diese Farm-Konfiguration verwenden, um eine höhere Auslastung, eine hohe Verfügbarkeit der externen Sharepoint Sites und um SQL Server AlwaysOn für eine Sharepoint-Farm zu testen.

Für die Konfigurationsdetails der beiden Farmen klicken Sie bitte hier.

Diese Farms haben einen vorkonfigurierten Endpoint, um authentifizierten Web Traffic (TCP Port 80) auf dem Sharepoint-Web-Server über einen mit dem Internet verbundenen Client-Computer zu ermöglichen. Dieser Endpunkt ist eine vorkonfigurierte Teamwebsite. Um auf diese Teamwebsite zu zugreifen, gehen Sie wie folgt vor:

  1.      Im Azure Portal klicken Sie auf “Suchen”, und klicken Sie dann auf “Ressourcengruppen”.
  2.      In der Liste der Ressourcengruppen klicken Sie auf den Namen Ihrer Sharepoint-Farm Ressourcengruppe.
  3.      Klicken Sie innheralb Ihrer SharePoint-Farm Ressourcengruppe auf Bereitstellungsverlauf.
  4.      Im Bereitstellungsverlauf rufen Sie Microsoft.SharePointFarm auf.
  5.      Unter Microsoft.SharePointFarm kopieren Sie die URL, die im Feld SHAREPOINTSITEURL zusehen ist.
  6.      In Ihren Internet-Browser fügen Sie die URL in das Adressfeld ein.
  7.      Geben Sie bei der Aufforderung die Anmeldeinformationen (Benutzer-Account), die Sie beim Erstellen der Farm hinterlegt haben, ein.

Innerhalb der Zentraladministration der SharePoint-Site können Sie MySites, SharePoint-Anwendungen und andere Funktionen konfigurieren. Weitere Informationen zur Konfiguration von Sharepoint 2013 gibt es hier.

Um Zugriff auf die Zentraladministration zu erlangen, setzen Sie folgende Schritte um:

  1. Im Azure Portal klicken Sie auf “Suchen” und anschließend auf “Ressourcengruppen”.
  2. In der Liste der Ressourcengruppen klicken Sie auf den Namen der Sharepoint-Farm-Ressourcengruppe.
  3. Klicken Sie im Bereich für Ihre Sharepoint-Farm Ressourcengruppe auf Bereitstellungsverlauf.
  4. Im Bereitstellungsverlauf rufen Sie Microsoft.SharePointFarm auf.
  5. Unter Microsoft.SharePointFarm kopieren Sie die URL, die im Feld SHAREPOINTCENTRALADMINURL zusehen ist.
  6. In Ihrem Internet-Browser, fügen Sie die URL in das Adressfeld ein.
  7. Geben Sie bei der Aufforderung die Anmeldeinformationen (Benutzer-Account), die Sie beim Erstellen der Farm hinterlegt haben, ein.

Hinweise:

Das Azure Portal erstellt diese virtuellen Maschinen innerhalb Ihres Abonnements und in einem cloudbasierten, virtuellen Netzwerk. Es gibt keine Site-to-Site-VPN-Verbindung zurück zu Ihrem Unternehmensnetzwerk. Sie können diese Server über Remote-Desktop-Verbindungen einfach verwalten.

Um Ihre Sharepoint-Farm mit Azure zu erstellen, gehen Sie folgendermaßen vor:

  1. Im Microsoft Azure Portal auf Virtual Machines und dann auf Sharepoint Server Farm klicken.
  2. Im Sharepoint-Farm Bereich, geben Sie den Namen einer Ressourcengruppe an.
  3. Geben Sie einen Benutzernamen und ein Kennwort für ein lokales Admin-Konto für jede virtuellen Maschine in der Farm an.
  4. Wenn Sie die Hochverfügbarkeitsfarm möchten, klicken Sie auf Aktivieren von hoher Verfügbarkeit.
  5. Um den Domänencontroller zu konfigurieren, klicken Sie auf den Pfeil. Sie können einen Hostnamen-Präfix (die Standardeinstellung ist der Ressourcen-Gruppenname) wählen und geben Sie bitte einen Struktur-Stammdomänennamen (Standard ist contoso.com), und die Größe der Domänen-Controller (Standard ist A1) an.
  6. Um Ihren SQL-Server zu konfigurieren, klicken Sie auf den Pfeil. Sie können einen Hostnamen-Präfix (die Standardeinstellung ist der Ressourcengruppen-Name)  und die Größe des SQL-Servers (Standard ist A5) wählen. Geben Sie danach das Datenbankzugriffskonto und das Passwort an, und geben Sie den Namen des SQL-Server-Dienstkontos (der Standard ist SqlService) und das dazugehörige Passwort (Standardmäßig ist das gleiche Kennwort, wie es beim Administrator-Konto gewählt wurde, hinterlegt).
  7. Um Ihren Sharepoint-Server zu konfigurieren, klicken Sie auf den Pfeil. Sie können einen Hostnamen-Präfix (die Standardeinstellung ist der Ressourcegruppen-Name) und die Größe des SharePoint-Servers (Standard ist A3) wählen. Standardmäßig wird das Administratorpasswort für das SharePoint-Benutzerkonto, Farmkonto und Passwort verwendet.
  8. Um optionale Konfiguration (Ihr virtuelles Netzwerk oder Speicherkonto, Diagnosen) durchzuführen, klicken Sie auf den entsprechenden Pfeil.
  9. Um das Abonnement zu spezifizieren, klicken Sie auf den entsprechenden Pfeil.
  10. Um den Ort (Region) anzugeben, klicken Sie auf den entsprechenden Pfeil.
  11. Wenn Sie fertig sind, klicken Sie auf Erstellen.
https://portal.azure.com

https://portal.azure.com

Sharepoint Server-Farm verwendet den Azure Resource Manager mit entsprechenden Powershell-Skripten, um die Infrastruktur und die Server-Konfigurationen automatisch zu erstellen. Weitere Informationen finden Sie unter Verwendung von Windows Powershell mit Resource Manager.

Erfahren Sie mehr zum Thema Microsoft Azure und Datensicherheit in der Cloud zu unserer gemeinsam im Nov/Dez 2014 stattfindenen Roadshow “Cloud Executive Business Brunch” mit Microsoft. Mehr Details zu den Events erfahren Sie unter folgendem Link.

Autor: Sascha Blickensdörfer

PT_XING_SBlickensdoerfer

Erweiterung der Hardware-Inventur mit dem ConfigManager 2012

Montag, 16. Juni 2014

Scientist at vintage laboratoryDer Configuration Manager 2012 bietet bereits ein breites Spektrum an Hardware-Inventurklassen. Mit diesen ist es möglich, eine Vielzahl von Informationen auf den Clients auszulesen. Dennoch ist es mitunter nötig, die Hardwareinventur um eigene Klassen zu erweitern.

In diesem Beispiel sollen Registrierungseinträge auf einem Client, über die Erweiterung der Hardwareinventur im Configuration Manger 2012, ausgelesen werden. Die Einträge in der Registry enthalten Informationen über Software, die auf dem Client installiert ist.

Bild 1

Software, die auf dem Client installiert ist

Für die Erweiterung der  Hardwareinventarisierung um die oben gezeigten Registrierungseinträge wird zunächst auf dem primären Standortserver ins Verzeichnis <Installationsverzeichnis des Configuration Managers>\inboxes\clifiles.src\hinv gewechselt. In dem Verzeichnis befindet sich die configuration.mof, die vor der Bearbeitung gesichert werden sollte. Geöffnet mit dem Editor, bietet die Datei unter dem Punkt Added extensions start die Möglichkeit, diese um eigene Klassen zu erweitern.

Bild 2

Im Beispielskript wird die oben gezeigte Schlüsselstruktur an der Stelle HKEY_LOCAL_MACHNINE\ProTechnology\Maintenance durchlaufen. Für jeden Eintrag der unterhalb von Maintenance, die für ein Softwarepaket steht, wird in der Klasse ein Objekt angelegt. In diesem Objekt werden die Zeichenfolgennamen mit den dazugehörigen Zeichenfolgenwerten der Registry gespeichert.

Eine besondere Funktion des Beispielskriptes ist es, dass nicht nur die Inhalte eines Registry-Eintrages erfasst werden, sondern alle Schlüssel, die dieser beinhaltet. Auf diese Weise kann ein Schlüssel erfasst werden, der noch gar nicht bekannt ist, solang sich sein Inhalt an den seiner Vorgänger orientiert.

Nachdem alle Änderungen vorgenommen sind, muss die configuration.mof gespeichert und mittels des CMD-Befehles mofcomp –check auf Fehler überprüft werden. Ist die Überprüfung ohne Fehler bestanden, wird mit mofcomp (ohne -check) die neue Klasse registriert.

Bild 3

Klassen mit SCCM 2012 registriert

Sollte der Dateiname und Pfad geändert worden sein, muss bei der Registrierung darauf geachtet werden, dass die originale Pfad- und Dateibezeichnung wiederhergestellt wird. Die neue Klasse steht sonst nicht in der nachfolgender Auswahl zur Verfügung, auch wenn mofcomp keine Fehler wirft.

Um die Hardwareinventur der Clients zu erweitern, wird in diesem Beispiel im Configuration Manager die Default Client Settings um die neue Klasse erweitert. Dazu im Bereich Administration des Configuration Managers in die Client Settings wechseln. Unter Eigenschafen den Punkt Hardware Inventory auswählen und über Set Classes und Add… im öffnenden Fenster den Computernamen und den WMI-Namespace eingeben. In der angezeigten Liste kann nun die neue Klasse ausgewählt werden.

Bild 4

Mit SCCM die Klasse auswählen

Bild 5

 

Getestet werden kann die Änderung durch das Anstoßen der Hardwareinventur im Configuration Manager auf einem Testclient.

Bild 6

Anstoßen der Hardwareinventur im Configuration Manager

Zurück im Configuration Manger auf dem Server sollten nach wenigen Minuten im Ressourcen Explorer des Testclients die Ergebnisse der Erweiterung zu sehen sein.

Bild 7

Autor: Karsten Aßmann

Ausblenden der Reparatur-Funktion im Kontextmenü (MSI / Windows Installer)

Montag, 02. Juni 2014

Blog_Reparatur_02062014Viele die sich mit Softwarepaketierung befassen kennen das: Die zur Installation gewünschte Software blendet beim ersten Start einen Konfigurationsdialog ein, welcher vom Systemmanagement jedoch nicht gewünscht ist, da es eine Standardkonfiguration für diese Software gibt.

Nach ein bisschen Recherche (Testinstallation und Testkonfiguration) stoßen wir darauf, dass nach dem ersten Durchlauf dieses Dialoges ein Registrykey (DisplayIntroPage) gesetzt wird. Des Weiteren wollen wir keine Updates (NextUpgradeCheck). Diese Registrykeys befinden sich unter HKEY_CURRENT_USER, damit wird für jeden sich anmeldenden Benutzer ein eigenes Set an RegKey gesetzt und jeder Benutzer hat möglicherweise eine andere Konfiguration. Um diese unterschiedlichen Konfigurationen zu vermeiden, gibt es mehrere Wege, wovon einer im Folgenden beschrieben wird. Als Vorbereitung sollte die Zielanwendung zuvor auf einem Testrechner installiert und entsprechen konfiguriert werden. Die Konfiguration sollte, wie in diesem Fall als Regdatei exportiert werden, um Fehler bei der Eingabe zu vermeiden.

Methode 1: Das Softwaremanagementsystem bietet die Möglichkeit, RegKeys vor dem Start der Anwendung unter dem Kontext des angemeldeten Benutzers zu setzen. Zum Beispiel bietet Novell ZCM diese Möglichkeit. Dies wird über den Novell Apllication Launcher realisiert.

Methode 2: Man nutzt die Selbstreparaturfunktion des Windows Installers, um die RegKeys zu setzen. Voraussetzung dafür ist, dass die Anwendungsshortcuts “Advertised” werden.

In diesem Beitrag wenden wir uns der Methode 2 zu und beleuchten, wie wir die Selbstreparatur anstoßen und somit für jeden Benutzer die Konfiguration in die Registry schreiben sowie die Anwendungskonfiguration für jeden Benutzer generalisieren. Wir verwenden für die Bearbeitung die Anwendung Installshield aus der Suite Adminstudio.

Schritt 1:

Als erstes öffnen wir das MSI, welches wir mit Installshield bearbeiten. Dafür mit einem Rechtsklick auf das MSI gehen und mit einem Klick auf „Edit with Installshield“.

Bild1

Schritt 2:

Als nächstes suchen wir uns das Feature, welches die Komponente enthält, die wiederum die Anwendung startet. Das Feature und die Komponente finden wir auf der Eigenschaftsseite des Shortcuts. Hier sehen wir, dass der Shortcut Advertised zur Komponente idea.exe im Feature Core ist.

Bild2

Schritt 3:

Haben wir das Feature gefunden, erstellen wir innerhalb dieses Features eine neue Komponente (hier User_Data), welche die von uns gewünschten Änderungen enthalten wird. Da es sich um RegKeys handelt, können wir den Zielpfad (Destination) weglassen und uns auf die Registry konzentrieren.

Bild3

Schritt 4:

Innerhalb der neuen Komponente befindet sich der für uns interessante Punkt Registry Data. Wir klicken auf diesen und im rechten Fenster öffnen sich 2 Ansichten: Die obere für den IST Zustand der Registry des aktuellen Computers und die untere für den Sollzustand. Nun klicken wir in der unteren Ansicht mit der rechten Maustaste auf den Schlüssel HKCU und dann auf “Import Reg”. Im Anschluss wählen wir die zuvor am Testrechner erstellte RegDatei aus und importieren den RegKey. Dieser wird nun entsprechend angezeigt. Wollen wir jedoch jeden RegKey als KeyPath, dann müssen wir für jeden RegKey eine Komponente anlegen.

Bild4

Schritt 5:

Zum Schluss ist es wichtig, dass ein RegKey als KeyPath markiert wird. Dieser KeyPath bildet im späteren den Entrypoint für die Selbstreparatur.

Schritt 6:

Sollte der Shortcut die Eigenschaft “Advertised” noch nicht besitzen, können wir das ändern, indem wir bei Advertised true auswählen. Wichtig ist, dass der Advertised Shortcut auf die Komponente zeigt, welche die Startdatei der Anwendung enthält.

Fazit

Von nun an wird die installierte Anwendung immer den Keypath abprüfen und bei Nichtbestehen nachinstallieren. Nach der erfolgreichen Installation sollte nun beim ersten Start der Anwendung die Selbstreparatur anfangen, d.h. die Konfiguration in Form der RegKeys nach HKCU zu schreiben. Danach startet die Anwendung mit der von uns gewünschten Konfiguration.

Viel Spaß beim Paketieren.

Autor: Sven Völkel

V

Es wird Zeit Ihr Rechenzentrum mittels Windows Azure und Power Shell zu erweitern!

Dienstag, 28. Januar 2014

blog_windows azure_rechenzentren_27012014In jüngster Zeit stoßen immer mehr Unternehmen und Provider an die Kapazitätsgrenzen Ihrer Rechenzentren. Die Lösung hierfür ist ein Service, der Ihnen die Ressourcen bedarfsgerecht zur Verfügung stellt. Ich habe schon ein paar Artikel über Windows Azure geschrieben, doch die Kombination aus der Microsoft Cloud und der Windows Power Shell spart Ihnen nicht nur Geld sondern auch jede Menge Nerven. In diesem Beitrag habe ich Ihnen gezeigt, wie Sie Azure einfach als zweites Rechenzentrum (RZ) nutzen und mit einem sicheren VPN Tunnel anbinden können.

Also, Powershell ISE auf und Feuerwerk!

Als Erstes importieren wir das Azure Powershell Modul und das Settingsfile, welches Sie bei Windows Azure passend zu Ihrem Abo herunterladen können und wählen die Subscription sowie den Storage Account aus, in dem der Server landen soll:

1_Import Azure Powershell Modul

Nun noch ein paar Details für den neuen Server definieren:

2_Auswahl des Basisimages

Auch der Cloud Service muss definiert werden.

3_Servicedetails

Was fehlt noch?

Die Domain, in die es gehen soll! Richtig, wenn Sie intern oder auch in Windows Azure ein Active Directory betreiben, können Sie den neuen Server direkt und automatisiert in Ihr AD aufnehmen.

4_domaindetails

Bauen wir uns das Ganze mal zusammen und erstellen endlich unsere virtuelle Maschine (VM).

5_zusammenfuehren der Konfiguration

Was passiert?

In die Variable $VM schreiben wir unsere komplette VM Konfig inklusive dem DomainJoin Provisioning. Mit dem Befehl „New-AzureVM“ erstellen wir die VM, den CloudService und joinen unsere VM in das Active Directory.

Über Anregungen und Fragen zu diesem Beitrag oder dem komplexen Thema Windows Azure freuen wir uns sehr.

Autor: Jens Decker

SCCM 2012 – Anlegen von Collections via Powershell

Montag, 12. August 2013

bildteaser_blog_082013Im ConfigMgr 2012 wurden zwar CMDLets hinzugefügt, aber leider kann man mit diesen nicht immer die gewünschten Funktionen umsetzen. Wie schon in den vergangen Versionen von SCCM 2007 heißt das Mittel der Wahl: WMI.

Eine Collection in der Konsole anzulegen ist nicht weiter schwer und geht recht schnell:

 console

Was aber wenn Sie 100 Collections anlegen müssen? Wenn Sie Ihr Software-Deployment automatisieren wollen? Für Jede Applikation benötigen Sie eine Installations- & Deinstallations-Collection. Das kann ganz schnell eine Aufgabe werden, die Sie nicht mehr manuell erledigen wollen! In unserem Beispiel haben wir einen “Collection-Ordner” angelegt, eine Collection erstellt und diese in den erstellten Ordner verschoben. Mittels SCCM 2007 war die Möglichkeit noch nicht gegeben, seine Collections über eine Ordnerstruktur übersichtlich gestalten zu können. Hier behalf man sich mit leeren “Sub-Collections”. Mit dem ConfigMgr 2012 ist dieser Weg nicht mehr von Nöten und auch nicht mehr funktional.

Im Fallbeispiel erstellen wir den Ordner “33Test” im  Root-Pfad der Collections. Natürlich ist es auch möglich eine komplette Struktur anzulegen:
Blog1

“$sitename” und “$Foldername” sind hier erstellte Variablen und müssen natürlich angepasst werden! Falls der Parent-Ordner nicht im Root liegt, ist die ContainerNodeID für den Parent-Ordner in der Class “SMS_ObjectContainerNodeID” zu ermitteln.

Im nächsten Schritt wurde eine Collection mit dem Namen “55Test” erstellt:

Blog22

Die nun angelegte Collection soll natürlich nicht im Root-Verzeichnis liegen, also verschiebt man diese, für die Übersichtlichkeit, in den zuvor angelegten Ordner: 

Blog3

Ein Blick in die AdminConsole zeigt, dass die Collection nun verschoben ist: 

Blog4

Viel Spaß beim Automatisieren! Sollten Sie Fragen zu Powershell oder dem ConfigMgr 2012 haben, sprechen Sie uns gerne direkt an!

Autor: Torsten Kraft

PT_XING_TKraft

Neue Ära – Wie wandelt sich die Technologie und die Anforderungen an die IT?

Freitag, 14. Juni 2013

blog_neue_era2Welche Hardware man benutzt, wird zunehmend egal. Wichtiger ist, dass uns unsere Daten überall zur Verfügung stehen, dank verschiedener Cloud-Dienste und kompatibler Hardware – alles kein Problem. Gleichzeitig stellt dies aber auch eine mannshohe Herausforderung sowohl für App-Entwickler als auch für Unternehmen, die Cloud-Dienste anbieten, dar. Letztlich erfordert es definitiv ein Umdenken beim Anbieter und Konsumenten. 

Zahlreiche Angebote an Hardware und Provider erhöhen die Anforderung an die Entwicklungsabteilung: Die meisten Menschen verwenden Windows PCs aber kein Windows Phone, sondern eher Android oder iPhone. Schon gibt es Inkompatibilitäten aufgrund unterschiedlicher Dienste. Würde man nur in der Windows-Welt bleiben, fehlten trotzdem einige Apps, die nicht für beide Systeme zur Verfügung stehen. Außerdem mag kaum ein Nutzer all seine Daten einem Anbieter anvertrauen. Bevorzugt wird ein Mix, der aber Apps auf allen Systemen voraussetzt. Auch wenn Tablets und Smartphones immer wichtiger werden: Laptops und PCs werden so schnell nicht verschwinden. Stattdessen werden weitere Kategorien hinzukommen, wie Smartwachtes, Wohnzimmerkonsolen, Media Server usw. . Auf all diesen Geräten soll möglichst ohne viel Aufwand Zugriff auf verschiedenste Daten erfolgen.

Eine App-Entwicklung muss somit mit möglichst vielen Systemen kompatibel sein, im besten Fall mit allen.

Anforderungen an moderne Applikationen ändern sich, wie schon erwähnt, ständig und immer schneller. Dies erfordert dementsprechend die Bereitstellung schnellerer, günstigerer, besserer, interaktiver Anwendungen mit rascher Bereitstellung und Auslieferung von Funktionalität. Dafür erforderlich ist ein angepasster Lebenszyklus mit den wichtigsten Elementen Feedback, Qualität und Lieferung. ProTechnology hat den Weg erkannt und nutzt bei der App-Entwicklung agile Prinzipien: Development in kleinen Iterationen mit dem Ziel, diese so schnell wie möglich zu durchlaufen.

Agile Softwarentwicklung

Agile Web- und Software-Entwicklung

 

Wie bereits festgestellt, kann sich jeder Mitarbeiter oder jede Privatperson aus den verlockenden Angeboten an Tablets, Phablets, Smartphones, Hybriden oder Laptops einen bevorzugten Mix zusammenstellen. Diese Welle wird auf Unternehmen überschwappen: In Zukunft möchten Mitarbeiter ihre eigenen Geräte beim Arbeitgeber mitbringen können. Unternehmen müssen somit darüber nachdenken, „Bring Your Own Device (BYOD)“ zu unterstützen.

Nur wie realisiere ich es, dass auf privaten Geräten unternehmensrelevante Daten sichtbar werden?

BYOD bedeutet gleichzeitig eine Kostenersparnis für Unternehmen. Viele IT-Entscheidungsträger äußern allerdings Risiken für die Sicherheit ihres Unternehmensnetzwerks, die mit BYOD in Verbindung gebracht werden. ProTechnology hat sich zu diesem Thema Gedanken gemacht, wie dieser Skepsis mit aktuellen Microsoft-Technologien entgegen gewirkt werden kann. Mit SCCM.eu haben wir den System-Manager SCCM in die Cloud gehoben. Den Unternehmen wird eine ConfigManager 2012 SP1 CU1 Infrastruktur bereitgestellt, die sich leicht in die bestehende Umgebung (Active Directory uvm.) integrieren lässt. BYOD ist mit SCCM.eu nun sicher: Ihre Mitarbeiter bekommen auf Wunsch, den Zugang zu einer für Sie individuell gestalteten Unternehmenswebseite. Dort haben diese nach vorheriger Anmeldung die Möglichkeit ihr eigenes Notebook, Tablet oder auch Windows Phone, sowie jedes andere Smartphone, in Ihrem SCCM.eu-Mandanten zu registrieren. Das Gerät kann im Nachgang leicht mit wichtiger Software betankt werden und Ihnen steht es zu jeder Zeit frei, das Gerät aus dem Unternehmensnetzwerk wieder zu entfernen.

Der IT-Abteilung steht ein Wandel bevor.

Sie müssen sich aus den eben genannten Gründen neu definieren und neu ausrichten. Genauso, wie der IT-Dienstleister: Er entwickelt sich vom traditionellen IT-Betreiber hin zum Service Anbieter. Er agiert als Partner und nimmt die Business-Anforderungen seiner Kunden auf und versucht mit den jeweils passenden Services kosteneffizient die geforderte Qualität und dem Compliance-Anspruch gerecht zu werden.

Wir befinden uns am Beginn einer neuen Ära, in der sich Technologie, wie vorgestellt, endlich dem Menschen zuwendet. Nicht wir passen uns der Technik an, sondern die Technik passt sich uns an. Über diese Themen berichtet die ProTechnology gemeinsam mit Microsoft am 05.06.2013 in der Think:ademy. Die Teilnehmer erfuhren im Rahmen der „New Era“-Veranstaltung, warum Microsofts neue Mission Vielfalt und Wahlfreiheit ist, und in deren Ausdruck Services und Devices die Hauptrolle spielen. Haben Sie die Veranstaltung verpasst, aber Interesse an diesem Thema, so sprechen Sie uns. Wir zeigen Ihnen gerne anhand von vielen unterhaltsamen Beispielen den technologischen Wandel.

SONY DSC SONY DSC
“New Era”-Veranstaltung @Think:ademy, Dresden

Autor: Melanie Wolf

SCCM 2012 SP1 CU1 – Warum verweigern die ManagementPoints den Dienst?

Donnerstag, 25. April 2013

bildteaser_managementSeit langem melde ich mich mal wieder mit einem Blog über den ConfigMgr 2012 zurück. Nachdem wir nun ein paar Wochen getestet haben, konnte diese Woche das CU1 für den ConfigMgr 2012 SP1 in unser Produktivsystem eingespielt werden.

Und wie das immer so ist, erstens kommt es anders und zweitens als man denkt! In unserer Testumgebung, die dem Produktivsystem absolut gleicht (dachte ich zumindest), verliefen alle Installationen problemlos. Aber als wir das CU1 im Produktivsystem verteilt haben, waren unsere ManagementPoints plötzlich der Meinung ihren Dienst zu verweigern.

Doch warum ist das so?

Nun die MP Rolle sollte vom ConfigMgr automatisch neu installiert werden. Dies blieb jedoch mit der folgenden Commandline in der MPSetup.log hängen:

Installing E:\Microsoft Configuration Manager\bin\x64\mp.msi CCMINSTALLDIR=”E:\SMS_CCM” CCMSERVERDATAROOT=”E:\Microsoft Configuration Manager” USESMSPORTS=TRUESMSPORTS=80 USESMSSSLPORTS=TRUE SMSSSLPORTS=443 USESMSSSL=TRUE SMSSSLSTATE=0 CCMENABLELOGGING=TRUE CCMLOGLEVEL=1 CCMLOGMAXSIZE=1000000 CCMLOGMAXHISTORY=1

Nach genauerem Betrachten des Logs fiel mir ein kleiner syntaktischer Fehler auf:

USESMSPORTS=TRUESMSPORTS=80

Eindeutig: Hier fehlt ein Leerzeichen!

Wir konnten den Fehler nur in unserm Produktivsystem beobachten, auf allen anderen Systemen lief die Installation problemlos durch.

Die entsprechenden Server haben die folgenden Specs:

System: W2k8 R2 SP1
Patchstand: aktuell
ConfigMgr Partition losgelöst von der System Partition.

Sollten Sie dasselbe Problem haben, hilft der Aufruf der Commandline mit privileged Rights. Danach sollte sich der MP wieder normal verhalten!

Autor: Jens Decker

Windows Azure mit VPN (Vyatta) verbinden

Freitag, 04. Januar 2013

Aus aktuellem Anlass ist es mal wieder Zeit, etwas über Windows Azure zu berichten. Viele Unternehmen stehen gerade vor dem Problem, was mit dem „alten“ TMG 2010 Server passieren soll, jetzt wo das Produkt offiziell nur noch bis 2015 von Microsoft unterstützt wird. Aus diesem Grund nehme ich ein Feature, das mich in den letzten Wochen vor dem Jahreswechsel viel beschäftigt hat: das Azure Network Feature. 

So soll es aussehen:

Wenn Sie in Ihrer Subscription von Windows Azure (Netzwerkübersicht) Ihr Netzwerk auswählen und das obige Bild sehen, haben Sie alles richtig gemacht. Aber wenn Sie nicht gerade einen teuren Cisco Router oder eine Juniper Firewall Lösung einsetzen (hierfür gibt es Konfigurationsdateien zum Download), ist der Weg bis dahin steinig und schwer. “Ich möchte an dieser Stelle darauf hinweisen, dass Microsoft nicht mal für seine eigenen Produkte (TMG 2010, ISA, UAG) Konfigurationsbeispiele direkt verlinkt.” Es gibt natürlich Alternativen zu Cisco und Co., eine davon werde ich in diesem Beitrag vorstellen und das VPN erläutern. Wir, bei der ProTechnology GmbH, setzen seit einiger Zeit eine Routerlösung von Vyatta ein. Der Vorteil, diese Version ist vollkommen kostenlos und der Konfigurationsaufbau erinnert an Cisco.

Nun aber zur Konfiguration!
Zuerst legen wir in unserer Azure-Subscription ein neues Netzwerk an. Zur Veranschaulichung haben wir hier den Namen „VPN-Test“ und die Affinitätsgruppe „Test-VPN“ gewählt.

Als Nächstes benötigen wir für unser virtuelles Netzwerk einen Adressraum (10.0.0.0/24) und unterhalb des Adressraumes definieren wir das passende Subnetz, also 10.0.0.0 – 10.0.0.15.

Da wir unser Azure VPN Network an unser Corporate Network anbinden werden, macht es natürlich Sinn einen internen Servernamen für die Azure-VMs anzugeben. Damit eröffnen wir uns auch gleich die Möglichkeit, diese an das lokale Active Directory zu binden. In unserem Fall ist einer der Test-Domain-Controller unter der IP 10.0.1.100 zu erreichen. Jetzt kommt der erste eigentliche Schritt der IPSec-VPN Konfiguration: wir geben unser Gateway-Netzwerk an.

Wichtig ist es, dass sich das Netzwerk in dem zuvor gewählten Adressraum befinden muss und es darf sich nicht mit einem vorhandenen Subnetz überschneiden. Die Schemaübersicht des virtuellen Netzwerkes, im unteren Teil des Bildes ersichtlich, füllt sich langsam mit Leben und zeigt uns an, wie es aussehen soll:

Danach definieren wir noch unser lokales Netzwerk. In unserem Fall sind das die Netze 10.0.1.0/24 (hier befindet sich unser DC) und 10.0.2.0/24. Wir vergeben einen Namen für das lokale Netz und hinterlegen die IPv4 WAN Adresse des Vyatta Routers.

Nun brauchen nur noch den zweiten Endpunkt unseres IPSec Tunnels. Dafür müssen wir einen Gateway bei Azure erstellen. Das geht widererwartend einfach. Wir klicken unten links auf „Gateway erstellen“ und warten bis Azure die Arbeit für uns erledigt hat und wir eine IPv4 Adresse zugewiesen bekommen.

Diese IPv4 benutzen wir dann in unserem Config-File für die Vyatta, um den Azure Endpunkt zu definieren. Nun brauchen wir nur noch den IPSec Pre-Shared-Key. Diesen bekommen wir aus der Konfiguration unseres Netzwerkes über „Schlüssel verwalten“ und „einen Key erstellen lassen“.

Nun die Vyatta Konfiguration - Sie werden sehen, jetzt geht es drei Mal so schnell ;-)

Wir erstellen eine neue IKE Gruppe mit dem Namen „azure” und den unten genannten Eigenschaften. Diese Werte können Sie in einem MSDN Artikel und in den oben genannten Config-Files für Cisco und Juniper auslesen.

Config-Path: VPN àIPSec à IKE-Group

ike-group azure {
     lifetime 28800
     proposal 1 {
         dh-group 2
         encryption aes128
         hash sha1
     }
 }

Nun brauchen wir noch die passende ESP Gruppe. Auch hier nehmen wir wieder der Name „azure“ und die unten genannten Eigenschaften. Diese Werte sind ebenfalls von Microsoft vorgegeben.

Config-Path: VPN àIPSec à ESP-Group

esp-group azure {
     lifetime 3600
     pfs disable
     proposal 1 {
         encryption aes128
         hash sha1
     }
 }

Zum Schluss müssen wir an der Vyatta noch die Site-to-Site Konfiguration vornehmen. Dazu brauchen wir die Gateway IP und den Pre-Shared-Key von Azure.

Config-Path: VPN àIPSec à Site-to-Site

peer x.x.x.x {                                         // (IP des Azure VPN Gateways)
 authentication {
      mode pre-shared-secret
      pre-shared-secret Pre-Shared-Key                  // Pre-Shared-Key aus Azure
  }
  connection-type respond  // wichtig, respond verwenden/Verbindungsherstellung durch Azure
  default-esp-group azure
  description "Windows Azure Subscription"
  ike-group azure
  local-address x.x.x.x                                 // WAN IP der Vyatta
  tunnel 1 {
      local {
          prefix 10.0.1.0/24                                    // lokales Netzwerk des Nameservers
      }
      remote {
          prefix 10.0.0.0/24                                    // Azure Netzwerk
      }
  }
  tunnel 2 {
      local {
          prefix 10.0.2.0/24                                    // zweites lokales Netzwerk
      }
      remote {
          prefix 10.0.0.0/24                                    // Azure Netzwerk
      }
  }
         }

Endlich fertig. Nun wird Ihre VPN, nach dem Sie in Azure auf “Verbinden” geklickt haben, online sein, Sie können nun VMs an das virtuelle Netzwerk bei Windows Azure anhängen und diese aus Ihrem lokalen Netz erreichen.

Über Anregungen und Fragen zu diesem Beitrag oder dem komplexen Thema Windows Azure freuen wir uns sehr.

P.S.: Mit der Anleitungen auf www.vyatta.org oder einem Consultant von ProTechnology ist die Ablösung des TMGs kein Problem mehr!

Quelle: www.vyatta.org, MSDN Artikel
Autor: Jens Decker

 

Das war unser IT-Jahr 2012 und so geht es weiter …

Freitag, 21. Dezember 2012

„Es wird noch größer, spektakulärer und noch viel effizienter…“ hört man oft zu Beginn des Jahres, vor allem, wenn man von High-Tech-Trends für das kommende Jahr spricht. Doch ist das wirklich so? Die Mitarbeiter von ProTechnology haben sich digital in einem Diskussionsforum zusammengefunden und das Jahr 2012 Revue passieren lassen: „Liebe Kollegen, war es denn noch größer, spektakulärer und effizienter als das Jahr zuvor?“ Die Meinungen sind gespalten – klar bei ProTechnology und in der Welt ist viel passiert und innoviert wurden, jedoch sagt die Kristallkugel für das Jahr 2013 noch viel mehr Effizienz voraus. Wer hätte das gedacht. Warum? Es wird noch mehr mobiles Internet, noch mehr Social Media, noch mehr Digitalisierung geben, nicht nur allein, weil Microsoft seine komplette Office-Welt umstellt. Das moderne, überall auffindbare Büro ist nicht mehr allzu weit von uns entfernt. Zunächst schauen wir aber zurück.

Für ProTechnology war es ein sehr gelungenes Jahr. Wir veröffentlichten viele neue Kunden-Success-Stories,  aber auch neue Mitarbeiter begrüßten wir im ProTechnology-Team. Erst kürzlich haben wir zwei Studenten der HTW im Rahmen des Deutschlandstipendiums im Team hinzugewonnen. Auf diesem Weg nochmal „Herzlich Willkommen“

Doch was gab es noch Neues?

Microsoft hat auf der diesjährigen SharePoint Conference 2012 die neue Version 2013 im Detail vorgestellt. 10.000 Besucher aus 85 Ländern sind dem Ruf gefolgt und ProTechnology war mittendrin. Neben deutlichen Verbesserungen im User Interface steht Social Collaboration im Vordergrund: Allem kann gefolgt und alles kann ge-liked werden.

Im viel kleineren Stil, aber mit gleicher Aufregung, war unser Vortrag einen Tag vor Nikolaus auf dem Mitteldeutschen Unternehmertag 2012. Auf großer Bühne präsentierten drei ProTechnology-Kollegen und Jörg Jasper von Microsoft alles zum Thema „Optimieren Sie Ihren Vertrieb und gewinnen Sie strukturiert, aber garantiert neue Bestandskunden“ Hier mal ein kleiner Eindruck:

Doch auch in unserem allgemeinen Arbeitsalltag hat sich Einiges getan: Die Software der ProTechnology wird nun nicht mehr per Turnschuhadministration verteilt, sondern durch SCCM 2012. Das ist auch ein wichtiger Schritt, vor allem, da wir zu Beginn des neuen Jahres zwei neue Standorte mit Stuttgart und Zwickau, hinzubekommen sowie die Büroräume in Dresden um zwei Etagen weiter ausgebaut werden, denn so langsam wird es eng in der dritten Etage der Antonstraße 3a. Apropos dritte Etage – der Blick aus unseren oberen Büroetagen ist, gerade zu Weihnachten, herrlich:

Windows 8 und Office 2013 setzen auf die Cloud. 2012 stand auch im Zeichen der Cloud und wir garantieren jedes weitere Jahr wird ein Cloud-Jahr sein, denn dieser Trend ist nicht nur eine Phase. Genau aus diesem Grund haben wir schon umgerüstet und ProTechnology ist fast vollständig in die Wolke transferiert: Wir migrierten in diesem Jahr unseren Lync-Server und den Team Foundation Server in die Cloud. Ob sich der Umzug dahin gelohnt hat, erfahren Sie hier.

Auch das moderne Office ist bei uns schon längst da: Alle Mitarbeiter arbeiten seit Wochen mit Windows 8, Office 2013 und Lync 2013. Was sagen die Kollegen dazu?

Ich finds knorke!           Viele neue praktische Features!              Es ist irgendwie… Neu :)           Neu und cool! Chic :)     Office 2013 und Windows 8 ein wenig design-arm, dafür praktischer geworden.     Ich bin schon app-süchtig.         Noch schneller, noch besser integiert. optimal für effizientes Arbeiten – privat und im Unternehmen :)

Ausblick

In der Einleitung wurde es bereits erwähnt, es wird noch mehr mobiles Internet, noch mehr Social Media, noch mehr Digitalisierung geben, nicht nur allein, weil Microsoft seine komplette Office-Welt umstellt. Doch was kommt da 2013? Die großen vier Trends aus dem Vorjahr „Mobile IT, Cloud Computing, Big Data und Social Media“ sind zum Großteil auch die Prognosen für das Jahr 2013, denn diese Themen sind so einschneidend, dass sie noch über Jahre aktuell sind. Der Punkt “Mobile Apps und/oder HTML5“ kommt 2013 noch hinzu. Erwartet wird ein langfristiger Wandel hin zu dem neuen Web-Standard HTML5. Trotzdem dürften die bei Usern von mobilen Endgeräten so beliebten Apps nicht einfach verschwinden. Bei der Programmentwicklung müssen sich die Unternehmen in den nächsten Jahren verstärkt darauf konzentrieren, noch optimalere Anwendungen für die mit Berührung gesteuerten mobilen Endgeräte zu entwickeln. Auch die Apps müssen für eine größere Bandbreite von Endgeräten tauglich gemacht werden.

In diesem Sinn wünschen wir unseren Blog-Lesern, Freunden, Partner und Kunden eine besinnliche Weihnachtszeit und ein erfolgreiches, innovatives Jahr 2013.

Autor: Melanie Wolf