TorstenM

Macht nichts. Einfach ignorieren. Diese Klasse ist halt auf dem Rechner nicht vorhanden. Nicht jede rote Zeile in cmtrace ist auch gleich ein echter Fehler.
Gut gemeinter Ratschlag: ConfigMgr kann man nicht einfach mal so nebenbei lernen und administrieren. Ich würde hierzu mindestens mal ein Buch lesen. Sonst rennst Du von einem "Problem" zum nächsten, aber kommst nie wirklich vorwärts.

Distribution Point

Was suchen jetzt php und MySQL hier? Hat mit ConfigMgr oder SQL überhaupt nichts zu tun.

Was hast Du denn *genau* vor (und schreibe jetzt nicht, daß Du "Hardware-Inventur-Dateien kopieren" willst).
Hast Du Dir schon einmal die Standard-Reports angeschaut, die mitgeliefert werden? Reichen die nicht?

Eine SQL-Abfrage könnte beispielsweise so aussehen. Dies soll aber nur als Beispiel dienen und müßte um alle anderen Inv.-Klassen erweitert werden (v_GS_*), was aber total unübersichtlich (und folglich nutzlos) wird:

select
vrs.Name0,
ws.*
from
v_R_System vrs
left join v_GS_WORKSTATION_STATUS ws on vrs.ResourceID = ws.ResourceID
where vrs.Name0 = 'Dein_PC_Name'
 

0x80072ee7 = ERROR_INTERNET_NAME_NOT_RESOLVED.
Was genau siehst Du denn im Task Manager? ccmsetup.exe? Das wäre dann aber nicht der Client, sondern nur der Bootstrapper-Dienst. Laut dem Logfile sieht es so aus, als könnte ccmsetup keinen DP ermitteln, von dem er die Client-Files herunterladen kann.
Ist denn das Client Package zu 100% auf den/die DPs verteilt? AD Schema erweitert? Kann die Site in den System Management Container schreiben?

Nein. Hardware Inventory wird nicht in einer Datei gespeichert. Weder auf dem Client, noch auf dem Server. Die Daten stehen alle in der Datenbank. Und da auch nicht in einer Tabelle, sondern verteilt in vielen.
Du kannst zB den Rechner in v_R_System "suchen" und dann über die ResourceID die gewünschten HardwareInventory-Views joinen (v_GS_*).

Wie oft bist Du selbst denn auf der Suche nach einer Problemlösung im Internet auf "habe das Problem gelöst" als Antwort gestoßen? Hat Dich das eventuell geärgert? Es wäre klasse, wenn Du schreiben würdest, wie Du das gelöst hast, damit andere auch davon profitieren können.
Welche Software wird denn wo nicht angezeigt? Geht's noch um den Resource Explorer / Software? Per default wird nichts inventarisiert. Dies müsste in den Client Agent Settings vorgenommen werden. Software Inventur (also zB welche *.exe findet sich wo) macht in den wenigsten Fällen Sinn (Client wird belastet und zu viel Informationen, mit denen sowieso nie jemand etwas anfängt). Hardware-Inventur liefert aber schon Add/RemovePrograms-Daten.
"SMS_SoftwareInstalled" kann man nicht "installieren". Meinst Du damit, dass Du dies in den Hardwareinventureinstellungen aktiviert hast?
Software synchronisieren? Wer von wo nach wo?

Auf diesem Wege zu importieren bringt Dir wenig bis nichts (es sei denn, Du willst auf einem bis dato unbekannten Recher ein neues OS installieren).
Zum Thema Discovery: http://technet.microsoft.com/en-us/library/hh427340.aspx und http://technet.microsoft.com/en-us/library/gg712308.aspx. Dann hast Du erst einmal den Rechner in der Datenbank (also prinzipiell eine Synchronisation der AD-Computerkonten mit der ConfigMgr-Datenbank; die Synchronisation ist aber "einseitig", d.h. von ConfigMgr Richtung AD passiert beim Discovery nichts).
Dann musst Du noch den ConfigMgr-Client installieren. Erst einmal: Finger weg von der automatischen Client Push Installation, nimm stattdessen den manuellen Push: http://technet.microsoft.com/en-us/library/gg712298.aspx.
Ich hoffe, dass diese ersten Gehversuche in einem Lab stattfinden. Mit ConfigMgr kann man sehr schnell sehr großen Schaden anrichten.

AD Discovery kann AD-Computerkonten ermitteln und der Datenbank hinzufügen.
Client kann über verschiedene Arten installiert werden; in deinem Fall wäre evtl die Client Push Installation die einfachste (Rechtsklick auf einen Rechner in einer Sammlung und "Install Client").

Ist denn auf dem Windows 7 Rechner ein ConfigMgr-Client installiert? Ohne Client auch keine Hard-/Software-Inventur.

Klar, das steht ja schon weiter oben in dem Thread. Ich würde aber eine Reinstallation von SQL bei einem produktiven Server vorziehen.

Guten Morgen Leute,

habe mich eben nochmal dran gesetzt und die englische Fassung von SQL Server 2008 Enterprise aufgesetzt da er ja die Server Collation SQL_Latin1_General_CP1_CI_AS haben möchte. Leider besteht immer noch der Fehler wie oben in dem 3 Scrennshot ( Server Collation = Latin1_General_CI_AS )  jetzt weiß ich leider nicht mehr weiter wie ich die Server Collation in SQL_Latin1_General_CP1_CI_AS ändern kann.

 

Habe eine angebliche Lösung gefunden nur jetzt besteht das nächste Problem :(

Warum sagt er mir bei dem Befehl: SQLADMINACCOUNTS Error ?

Name des SQL Server-Computers ( FQDN ) = Server.SCCM.LOCAL

 

 

 

Ich habe bei der SQL Installation den SCCM\Administrator als SQL Admin gewählt

Latin1_General_CI_AS <> SQL_Latin1_General_CP1_CI_AS

Bei der Installation von SQL nicht einfach alles wild durchklicken, sondern die Collation ändern. Die default ist die falsche.

Edit: jetzt erst habe ich den Screenshot angeschaut. Du willst SQL unattended installieren. Probier's doch für den ersten Versuch händisch. Ist sicher zielführender und einfacher, zumal gegen Ende der Installation automatisch eine ini generiert wird, die Du später weiterverwenden kannst.

 

<unattend xmlns="urn:schemas-microsoft-com:unattend">

  <settings pass="windowsPE">

      <component name="Microsoft-Windows-International-Core-WinPE" publicKeyToken="31bf3856ad364e35" language="neutral" versionScope="nonSxS" processorArchitecture="x86">

 <SetupUILanguage>

                <WillShowUI>OnError</WillShowUI>

                <UILanguage>en-US</UILanguage>

     </SetupUILanguage>

            <UILanguage>en-US</UILanguage>

        </component>

    </settings>

</unattend>

 

 

Das muss man doch irgendwo passend angeben können!

 

 

Kann man. Du hast in dem Fall aber das falsche OS gewählt. Verwende einfach das WSIM um die unattend.xml zu erzeugen. Dabei ist dann noch wichtig, die richtige Architektur (x86 / x64) des Ziel-OSes auszuwählen.

Du kannst das xml-File auch händisch erstellen - aber AIK/ADK sind besser geeignet ;-)

Ich würde MDT in ConfigMgr integrieren; damit hast Du mehr und einfacherer Möglichkeiten, die OS-Deployments flexibel zu gestalten.
Weiterhin kannst Du mit dem Windows AIK bzw ADK einen unattend.xml erstellen und in dieser die Spracheinstellungen vornehmen. Ich würde aber eher zu der MDT-Integration tendieren und die Sprachsettings in der MDT-Datenbank setzen.

Du brauchst mind. das SP1 für ConfigMgr 2012 (http://technet.microsoft.com/en-us/library/jj822982.aspx#BKMK_Supp). Die Clients müssen entsprechend auch SP1 und halt den AppV-Client haben.

Naja, es kommt halt drauf an, wen oder was man mehr quälen bzw nicht quälen möchte.

Theoretisch könnte man schon alle Deployments auf "All Systems" loslassen. Dann hätte der Server nicht wirklich viel zu tun, Collections zu evaluieren. Die Last wird dann allerdings auf die Clients verlagert. Jeder Client muss dann alle Policies herunterladen, evaluieren usw. Ebenso muß dies bei jedem Öffnen vom Software Center erfolgen. Außerdem hat man dann im Deployment Status sehr viele "Requirements not met"-Meldungen. Ich bin auch eher ein Freund von Collections - allerdings muß man das je nach Umgebungsgröße (Anzahl Rechner und zu verteilender Software) von Fall zu Fall entscheiden.

Requirement Rules sollten aber nicht zum "Targeting" verwendet werden; dies gehört definitiv in die Collection-Logik, so dass nur auf Rechner verteilt wird, die überhaupt versorgt werden sollen.

nur veträgt sich der wds 2012 mit dem confmgr 2012 nicht.... die müssen auf 2 verschiedene servern sein. 

Stimmt definitiv nicht. Funktioniert beides auf dem gleichen Server.

Was hast Du denn bei Option 66 und 67 angegeben? Siehst Du die Anfrage im SMSPXE.log?

Das Problem laut Screenshot ist, dass er Client das FlashPlayer Paket auf keinem Distribution Point finden kann. Vermutlich liegt dies an Boundaries bzw Boundary Groups.

... oder aber SP1 installieren, denn da ist diese Funktion bereits eingebaut.

Leider ist die wirklich wichtige Fehlermeldung nicht eingeblendet ("Weitere Informationen"). AppEnforce.log (Application) oder execmgr.log (Task Sequence / Package) auf dem Client können auch weiterhelfen. Oder alternativ auf der Monitoring Node der Konsole der Deployment Status.

Gibts denn dazu auch ein paar Infos? Ich finde nichts konkretes dazu, ob man die Updates per SCUP in einen WSUS veröffentlicht bekommt und die Clients das dann auch korrekt interpretieren können. Wäre nett, wenn du dazu einen Link o.ä. hättest.

 

Danke

Norbert

Mit SCUP kannst Du (eigene) Updates Richtung WSUS publishen, allerdings siehst Du die dann nicht in der WSUS-Konsole, um sie freigeben zu können. (Es sei denn, Du modifizierst die Datenbank händisch)

Wie gesagt, ich finde nur den einen Haken "Sending wake up packets" beim Verteilen eines Tasks. Mehr jedoch nicht.

Diese Option ("Send wake-up packets") wird pro Deployment konfiguriert und macht genau das, nämlich WoL zum Zeitpunkt der Deadline.

Nein, WoL geht auch per "magic packet". Siehe die Tabelle unter Planning for Communications in Configuration Manager ("Traditional wake-up packets")