“Nicht identifiziertes Netzwerk. Kein Internetzugriff.” unter Windows 7 lösen

Seit Jahr und Tag ärgere ich mich über die vermeintliche Intelligenz von Windows, beim Herstellen von Netzwerkverbindungen:

“Nicht identifiziertes Netzwerk. Kein Internetzugriff.”

Fuck you!

Nach vielem Suchen und dem Finden von ganz ausgefuchsten Lösungen bin ich nicht weiter gekommen.

+++WERBUNG+++ Professionell eine eigene Website erstellen +++WERBUNG+++

Die (für mich akzeptable) schlichte Brute-Force-Lösung sah dann schließlich so aus:

  1. Dienste-MMC aufmachen (Start -> Ausführen -> “services.msc”).
  2. Den Windows-Firewall-Dienst suchen.
  3. Diesen Dienst stoppen und deaktivieren.

Danach ging es endlich wieder.

Was mir außerdem geholfen hat, war der Tipp in diesem Technet-Artikel:

  1. Open an Administrator: Command Prompt. To do so, click Start, click All Programs, click Accessories, right-click Command Prompt, and then click Run as administrator.
  2. If the User Account Control dialog box appears, confirm that the action it displays is what you want, and then click Continue.
  3. At the command prompt, type the following command:
    netsh advfirewall set profiles state off

    where profiles is AllProfilesCurrentProfileDomainProfilePrivateProfile, or PublicProfile.

Ich habe mir dann konkret mit folgendem geholfen:

netsh advfirewall set AllProfiles state off

Was sogar auch mal geholfen hatte, war im Netzwerk-Center auf das rote X bei der symbolischen Leitung zu klicken und „Reparieren“ zu wählen. Das hatte ewig gedauert und danach hat es tatsächlich funktioniert.

Update 2013-12-06

Heute hatte ich einen Fall mit einem IBM-/Lenovo-Notebook, bei dem ich über WLAN dasselbe Phänomen hatte:

“Nicht identifiziertes Netzwerk. Kein Internetzugriff.”

Nach einer Stunde erfolglosem Try-and-Error habe ich aufgegeben und das Gerät via LAN-Kabel erfolgreich ans Netz bekommen.

Update 2013-12-09

Mein Kollege hatte ein ähnliches Phänomen (via WLAN) und hat es wohl dadurch gelöst, dass er sicher gestellt hat, dass der Gateway und DNS-Server alle im selben Subnetz sind. Dann wurde das Netzwerk automatisch erkannt.

Es war also eine reine IP-Einstellungs-Geschichte bei ihm, ganz ohne Firewall-und-Co.-Magie.

Update 2014-05-15

In einer VMware-Maschine habe ich das ganze gelöst bekommen, indem ich das Netzwerk von „Bridged“ auf „NAT“ umgestellt habe (in den Einstellungen der virtuellen Maschine).

Update 2014-08-15

In meiner VMware-Maschine wollte ich unbedingt wieder „Bridged“ haben. Ich habe lange gesucht und probiert, und die Lösung war letztendlich, beim „Bridged to“ von „Automatic“ auf meinen tatsächlichen LAN-Adapter umzustellen:

vmware-virtual-network-editor-bridget

Danach konnte ich erfolgreich wieder von der Maschine aus ins Internet und auch von meinem Lokalen PC auf die virtuelle Maschine kommen.

Shopware-4-REST-API von .NET 4 aus ansprechen

Zurzeit arbeite ich an einem Projekt bei dem aus Microsoft Navision („Dynamics Nav“ oder wie das jetzt heißt) heraus Daten nach Shopware geschrieben werden sollen.

Dazu scheint mit die REST-API von Shopware gut geeignet zu sein. Aus diesem Grund habe ich ein Beispielprojekt geschrieben. Das ganze ist eine .NET-4-Konsolenanwendung mit einer einzigen Datei.

Den Quelltext findet Ihr nachfolgend (alternativ auch bei Pastebin):

namespace ShopwareRestApiTest01
{
    using System;
    using System.Globalization;
    using System.Net;
    using Newtonsoft.Json;
    using RestSharp;

    internal class Program
    {
        static void Main()
        {
            const string user = "demo";
            const string pass = "NtMd3OIouT2sr0aJcllBIx1fH3SgxmRr0T6r7D4P";

            // http://restsharp.org/
            var client =
                new RestClient(@"http://192.168.147.169/api")
                    {
                        Authenticator = new DigestAuthenticator(user, pass)
                    };

            var request = new RestRequest("articles/{id}", Method.GET);
            request.AddUrlSegment("id", 3.ToString(CultureInfo.InvariantCulture)); // replaces matching token in request.Resource

            // easily add HTTP Headers
            request.AddHeader("Content-Type", "application/json; charset=utf-8");

            // or automatically deserialize result
            // return content type is sniffed but can be explicitly set via RestClient.AddHandler();
            var response = client.Execute(request);

            if (response.ErrorException != null)
            {
                Console.WriteLine(@"################ ERROR ################");
                Console.WriteLine(response.ErrorException.Message);
            }
            else
            {
                var content = response.Content; // raw content as string

                dynamic json = JsonConvert.DeserializeObject(content);
                Console.WriteLine(json);
            }
        }
    }

    public class DigestAuthenticator : 
        IAuthenticator
    {
        private readonly string _user;
        private readonly string _pass;

        public DigestAuthenticator(string user, string pass)
        {
            _user = user;
            _pass = pass;
        }

        public void Authenticate(IRestClient client, IRestRequest request)
        {
            request.Credentials = new NetworkCredential(_user, _pass);
        }
    }
}

In dem Projekt verwende ich auch zum ersten Mal NuGet, dem wirkliche eleganten Paket-Manager für Visual Studio. Damit lade ich Json.NET und RestSharp als Referenz in das Projekt.

Digest Authentication with RestSharp

Since RestSharp does not provide an authenticator for Digest Authentication, I simple wrote one that works for me.

Usage

var client =
    new RestClient(@"http://yourserver.com/api")
    {
        Authenticator = new DigestAuthenticator(userName, password)
    };

Implementation

The class is rather simple:

public class DigestAuthenticator : 
    IAuthenticator
{
    private readonly string _user;
    private readonly string _pass;

    public DigestAuthenticator(string user, string pass)
    {
        _user = user;
        _pass = pass;
    }

    public void Authenticate(
        IRestClient client, IRestRequest request)
    {
        request.Credentials = new NetworkCredential(_user, _pass);
    }
}

Enjoy! 🙂

Shopware erkennt mod_rewrite nicht

Gerade hatte ich den Fall, dass der Installer von Shopware penetrant behauptet hat, dass mod_rewrite nicht installiert sein, obwohl es tatsächlich installiert ist.

Die Lösung war dann, dass in der zentralen „httpd.conf“-Apache-Konfigurationsdatei der AllowOverride-Befehl

AllowOverride none

stand. Das hat dafür gesorgt, dass die Shopware-eigene mod_rewrite-Prüfung nicht aufgerufen wurde. Nach der Änderung auf

AllowOverride All

hat dann alles funktioniert. Nach der Änderung den Apache-Dienst neu starten, z.B. unter Windows über den Apache Service Monitor.

Fehlermeldung „Ein Clientvorgang ist fehlgeschlagen“ beim Öffnen fremder Postfächer in Outlook 2010

Obwohl ich Administrator bin, bekomme ich beim Öffnen von eingebundenen Microsoft-Exchange-Postfächern anderer Benutzer eine Fehlermeldung:

Der Ordner kann nicht erweitert werden. Ein Clientvorgang ist fehlgeschlagen.

Fuck for Outlook/Exchange.

Die Lösung (zumindest bei mir) sah dann so aus:

  1. Auf Exchange-Server mit RDP anmelden.
  2. Die „Exchange Management Console“ starten.
  3. Den Baum aufklappen:
    • Microsoft Exchange
    • Microsoft Exchange lokal
    • Empfängerkonfiguration
    • Postfach
  4. In der Liste im Hauptfenster dann das Postfach selektieren.
  5. Im rechten Bereich „Aktionen“ (oder via Rechtsklick auf Element) die Aktion „Berechtigung ‚Vollzugriff‘ verwalten…“ auswählen.
  6. Im erscheinenden Assistent auf „Hinzufügen“ klicken.
  7. Den entsprechenden Benutzer suchen, auswählen und mit „OK“ bestätigen.
  8. Den Assistent mit der „Verwalten“-Schaltfläche“ durchlaufen lassen.
  9. Via „Fertig stellen“ den Assistent schließen.

Ich musste dann mein Outlook 2010 nochmals starten, danach konnte ich aufs Postfach zugreifen. Insgesamt eher eine Brute-Force-Methode, für mich war’s ausreichend.