Jump to content


toratb

Established Members
  • Posts

    15
  • Joined

  • Last visited

Posts posted by toratb

  1. I know the SW inventory takes a long time to complete, but thats the price to pay for not impacting the server... Just "Create Custom Client Device Settings" and deploy it to a device collection containing only the file server. Also, make sure you run this at a time when it's convenient.

     

    If you are worried about "Slow Software Inventory Cycle", then set it up to only collect a few subdirectories from the server. This way you will get a few sample directories instead of the entire disk making the inventory cycle much faster since it's not gathering so much information.

     

    Thats just my two cents on the matter.

  2. Same procedure for a gateway server in DMZ

     

    1.1 - Generating the certificate

     

    RDP to your Operations Manager (it's a good idea to have all the certificates at one server)
    Start Internet Explorer and navigate to: https://yourCAserver/certsrv

     

    post-17845-0-03898200-1481014327.png

     

    post-17845-0-53010200-1481014327.png

     

    post-17845-0-93371400-1481014327.png

     

    post-17845-0-42781600-1481014328.png

    If the server in DMZ is in a domain, you need the FQDN (for example servername.domainindmz.local)

    If the server is in workgroup, the servername is sufficient

     

    post-17845-0-95931600-1481014328_thumb.png

     

    post-17845-0-46956000-1481014330.png

     

    post-17845-0-97595500-1481014330.png

     

    Export the Company Root Chain Certificate also! You need both installed on the server in workgroup/domain in DMZ in order for it to communicate with our servers.

     

    1.2 - Exporting the certificate to file

     

    Start – run – mmc.exe
    Add snap-in – Certificate – My User Account
    Find the Certificate we Generated and installed, right click and choose Export

     

    post-17845-0-49773400-1481014331.png

     

    post-17845-0-98739400-1481014331.png

     

    post-17845-0-12005800-1481014332.png

     

    post-17845-0-47493100-1481014338.png

     

    post-17845-0-94663300-1481014338.png

     

     

    Use a password (you will need it later)

     

    2 - Install agent and certificate

     

    Log on to the server in DMZ (remember to map local drive for copying files over)

     

    2.1 - Install agent

     

    2.1.1 - Uninstall the SCOM2007 agent if present

     

    post-17845-0-47172300-1481014339.png

     

    2.1.2 - Copy folders/files needed for install to server C:\temp

    \\tsclient\D\Backup\Setup\System Center 2012\SCOM\SW_DVD5_Sys_Ctr_Ops_Mgr_Svr_2012_English_MLF_X17-95297\
    AGENT
    SUPPORTTOOLS
    ServerName for scom2012.pfx

     

    post-17845-0-61472000-1481014339.png

     

    2.1.3 - Install SCOM2012 agent

     

    Use momagent.msi : (here C:\temp\AGENT\I386\MOMAGENT.MSI)

     

    post-17845-0-73012600-1481014339.png

     

    post-17845-0-85673100-1481014339.png

     

    NB! All certificates use FQDN, so your servers in DMZ need to have a reference to YourManagementServer.yourdomain.com in their HOSTS file
    Using the IP here will not work, you NEED the FQDN!

     

    post-17845-0-97144000-1481014339.png

     

    2.1.4 - Import Certificate

     

    Start – Run – cmd
    C:\temp\SUPPORTTOOLS\I386\MOMCERTIMPORT.EXE "C:\temp\ServerName for scom2012.pfx"

     

    post-17845-0-11208100-1481014340.png

    Update! Import the Root chain certificate on the server in workgroup/domain in DMZ also.

     

    post-17845-0-22750000-1481014340.png

     

    2.1.5 - Approve the manual agent in SCOM 2012 console

     

    post-17845-0-37494900-1481014340.png

     

     

     

    Error handling!

    Common mistakes is network equipment blocking ports for communication. A quick test it to use telnet on port to see if it can connect or not.

     

    Don't forget to use the eventlog!

     

    post-17845-0-33510300-1481014344.png

     

    -Tor

  3. Sometimes the error "The trust relationship between this workstation and the primary domain failed." occurs, and it's usually a pain to fix this. This is why I made a simple HTA application that easily fixes this error without ever leaving your computer!

     

    Requirements:

    You need to know the target's "computer name", "local administrator username" and "local administrator password"

    You also need a domain user/pass with the rights to join domain.

     

    The ONLY manual work you need to do is change the OU path;

    "OU=ExampleSubOU,OU=ExampleOU,DC=contoso,DC=org" to the OU path your company uses.

    If you forget to do this, it will fail with the following, ERROR: Domain Name not found!

    It only uses this OU path if the computer account does not exist in AD.

     

    This is what the application 1.0 looks like:

    post-17845-0-81652100-1479383790_thumb.png
     
    Newest version:

     

  4. My Custom Reports folder, so you can save some time. It includes the following:

    SCCM Count Microsoft Interesting Programs

    SCCM Count OS versions

    SCCM Get info on specific domain user

    SCCM Get info on specific OS

    SCCM Get info on specific Programs

    SCCM Index


    They are linked so you can click one item for more information.


    I also added some pictures for an example.

    Hope this will help someone.


    Newest version:



    -Tor

    Custom Reports.zip

    post-17845-0-98378900-1476702450.jpg

    post-17845-0-97366600-1476702454.jpg

  5. This is true......some models have the same family of drivers...so once imported previously into the driver store from another package it will not duplicate the same driver....bear in mind it is the model specific driver package that is important here...once the drivers are in the package everything should be OK

     

    Yeah, I think this is the case... I have tested the drivers that report wrong size, and they seem to work just fine. I have also asked at technet, but no replies just yet. (same title as this thread)

  6. Hello.

     

    This is my first post here. I have been using SCCM 2012 for a little while now. I have imported about 30-40 different PC models. About 20% of the models "failed". The wizard does not give any indication of any foul play, it all seems like everything went ok. But when I check the Monitoring - Content Status and compare the size (MB) of the package to the folder of the imported drivers, they "often" dont match.

     

    If I delete the Driver Package and delete the imported drivers, and do the same import again, I have managed to force some more models that previously had wrong size. I did the import exactly the same way, some times the size is wrong and sometimes the sizes is correct. I have no clue as to why it some times failes and some times work...

     

    I tried to look at the DriverCatalog.log, but didnt find anything interesting..

     

    Has any other then me experienced this problem?

     

    Can someone please check this

    Compare this "Monitoring" - "Content Status" - "Size (MB)"

    to the folder you use for imported driverpackages

    They should be the same size...

     

    PS. The driver with wrong size seem to work fine, so im wondering if this is just a bug to the "Monitoring" - "Content Status" - "Size (MB)" view... sometimes not updating correctly?

     

    Thanks :)

×
×
  • Create New...

Important Information

We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.