Jump to content


mniccum

Established Members
  • Posts

    18
  • Joined

  • Last visited

Posts posted by mniccum

  1. I appreciate your response.

     

    Are you referring to ADRs or AntiMalware policies? "to allow for different download settings for EP updates" is in the Antimalware Policies not in ADRs unless I am mistaken. I see the benefit of many Antimalware Policies (for file/folder exceptions) but the 13 ADRs for EP seems redundant if you aren't making any changes to the ADRs. Since definitions are downloaded daily I am not sure how much tweaking you would want to do to an ADR between different server ADRs. ADRs for Sotware Updates are a different story. A point was made about reporting so I would take that into consideration.

     

    Thanks Again

  2. I am just thinking out load here...

     

    What is the advantage of creating 13 individual ADR rules? They each do the same thing except they point to a different collection. Would there be any benefit to creating a master collection named for example Endpoint Protection Updates and adding all the individual collections under it? This way you only have one ADR for Endpoint Protection. Since definitions are downloaded every day, I don't think having the ability to create unique schedules would be that beneficial. I am trying to simplify this down for admins as there are 4 basic components involved which can be confusing for some: Collection, Antimalware Policy, Client Setting and ADR. Please let me know if I am overlooking something.

  3. I was able to find the SmsAdminUI.log on the second client tested. But keep in mind the other user can log in to the console from the machine where this log is generated from.

     

    [5, PID:5040][11/04/2013 15:49:32] :System.Runtime.InteropServices.COMException\r\nThe RPC server is unavailable. (Exception from HRESULT: 0x800706BA)\r\n at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
    at System.Management.ManagementScope.InitializeGuts(Object o)
    at System.Management.ManagementScope.Initialize()
    at System.Management.ManagementObjectSearcher.Initialize()
    at System.Management.ManagementObjectSearcher.Get()
    at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.Connect(String configMgrServerPath)\r\n
    [5, PID:5040][11/04/2013 15:49:32] :Transport error; failed to connect, message: 'The RPC server is unavailable. (Exception from HRESULT: 0x800706BA)'\r\nMicrosoft.ConfigurationManagement.ManagementProvider.SmsConnectionException\r\nThe RPC server is unavailable. (Exception from HRESULT: 0x800706BA)\r\n at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.Connect(String configMgrServerPath)
    at Microsoft.ConfigurationManagement.AdminConsole.SmsSiteConnectionNode.GetConnectionManagerInstance(String connectionManagerInstance)\r\nThe RPC server is unavailable. (Exception from HRESULT: 0x800706BA)
    \r\nSystem.Runtime.InteropServices.COMException\r\nThe RPC server is unavailable. (Exception from HRESULT: 0x800706BA)\r\n at System.Runtime.InteropServices.Marshal.ThrowExceptionForHRInternal(Int32 errorCode, IntPtr errorInfo)
    at System.Management.ManagementScope.InitializeGuts(Object o)
    at System.Management.ManagementScope.Initialize()
    at System.Management.ManagementObjectSearcher.Initialize()
    at System.Management.ManagementObjectSearcher.Get()
    at Microsoft.ConfigurationManagement.ManagementProvider.WqlQueryEngine.WqlConnectionManager.Connect(String configMgrServerPath)\r\n

  4. Configuration Manager cannot connect to the site (server.domain.com)

     

    I have a handful of users in a group called SCCMADMINS. All users can access the console from their desk and connect to ConfigMgr except for one. The user also tried logging in at another users desk and also could not access the console. That other user logged on before and after to the console successfully. Their is no log at "Program Files\Microsoft Configuration Manager\AdminConsole\AdminUILog". The client was installed from the R2 ISO. Just for a test I added the user explicitely to local admins on the server and in the the console and that person could still not log in.

     

    None of the other users are having issues.

     

    Any ideas?

     

    Thanks

     

    post-4029-0-11916000-1383603202_thumb.png

  5. After all the frustration I tried uninstalling and re-installing one last time..... and it is working!

     

    Here are the steps I took (almost with a restart with each step)

    • Uninstalled ADK 8.1
    • Removed boot images from Distribution points
    • Removed Boot Images from SCCM
    • Unchecked PXE deployment from Server and Site System Roles (Let SCCM uninstall WDS)
    • Removed RemoteInstall Directory
    • Re-downloaded and installed ADK 8.1
    • Turn on PXE deployment - check Distmgr.log file to see when it finishes
    • Add Boot Image from ADK to SCCM. Turned on the PXE deployment for these images
    • Distributed Boot Images

    The last step is where WDS has stopped working in the past, but today the WDS service stayed up and I was able to deploy one of my Windows 7 task sequences successfully.

     

    I was at the point where re-installing on Windows Server 2012R2 seemed like the only option.

     

    Good luck to anyone else with the same problems. Patience is definitely needed!

     

     

    I took the above advice but had to do it a bit different. When I checked the pxe box it would end up failing in the log becasue WDS would require a reboot. Here's what I did to solve my scenario:

     

    What did I do:

    Upgraded from ConfigMgr 212 SP1 CU2 to R2

     

    What was the issue:

    PXE hung at 0% loading "RemoteInstall\Boot\boot.sdi" (something like that)

    restarted WDS and it failed to start

     

    Environment:

    CAS with two Primaries (only one of the two Primary servers had the issue)

    Windows Server 2012

    SQL 2012 SP1

    VMWare 5.1 (VMXNET3 nic)

     

    Fix:

    Uncheck "deploy this boot image from the pxe-enabled dist point" on each boot image

    Uncheck PXE

    Check distmgr.log for uninstall success

    Reboot (before the reboot the wds service will be started) DONT SKIP THIS REBOOT OR IT WILL FAIL

    After reboot wds service will be gone

    Add wds, choose auto reboot

    Wait for wds to complete installation after reboot

    Check to make sure wds is set to manual and not started

    Rename or delete remoteinstall folder

    Check pxe box on the DP

    Check distmgr.log (filter to 'contains' wds) for success

    WDS service should be started and automatic

    Add new 8.1 boot images using copype.cmd process.

    Uncheck "deploy this boot image from the pxe-enabled dist point" on each OLD boot image

    Check "deploy this boot image from the pxe-enabled dist point" on each NEW boot image

    Distribute NEW boot images

    Wait for NEW boot images to be distributed

    RemoteInstall\SMSImages should contain 2 boot images

    Test PXE

     

    and as was said previously "Patience is definitely needed!"

     

    Thanks

  6. Here is whats logged in the app log when the WDS service fails to start:

     

    Fault bucket , type 0

    Event Name: APPCRASH

    Response: Not available

    Cab Id: 0

    Problem signature:

    P1: svchost.exe_WDSServer

    P2: 6.2.9200.16420

    P3: 505a9a4e

    P4: ntdll.dll

    P5: 6.2.9200.16579

    P6: 51637f77

    P7: c0000005

    P8: 000000000001af08

    P9:

    P10:

    Attached files:

    These files may be available here:

    C:\ProgramData\Microsoft\Windows\WER\ReportQueue\AppCrash_svchost.exe_WDSS_d3569a994248de8bc7363e9d6c83feaef59485_15fdef6c

    Analysis symbol:

    Rechecking for solution: 0

    Report Id: d365f71a-417f-11e3-9410-005056834a51

    Report Status: 4

    Hashed bucket:

  7. I am experiencing the same issue after an Upgrade from ConfigMgr 2012 SP1 CU2 to R2. The WDS service was running fater the upgrade but PXE would hang trying o load \smsboot\boot.sdi. I tried to restart the WDS service and got the same message as you. My log also looks the same. I rebooted and the WDS service still will not start. I have not spent any more time on it yet but if I find te resolution I will post it here.

     

    This was logged in the Admin log under Deployment-Services-Diagnostics before I restarted WDS:

     

    The Following Client failed TFTP Download:

    Client IP: x.x.x.x

    Filename: \SMSBoot\boot.sdi

    ErrorCode: 5006

    File Size: 3170304

    Client Port: 14145

    Server Port: 56290

    Variable Window: false

  8. Although this is a very viable option for including an HTA in the task sequence process I do not use it. The reason I do not use it is that I find my self changing the HTA a lot to add new functionality, etc. The way I do it is add the additional components to the boot images such as WMI, Scripting and HTA. This way I only have to mess with the boot images once. I fond compiling boot images over and over has the potential to fail frequently as I typically have many NIC and hard disk drivers included. Probably only an issue experienced by me though. Once the boot images are updated I just include my HTA in a new package and add it to the task sequence near the top of the task sequence right after WinPE boots. I have been doing this for years and in many different deployments but I have never seen it documented anywhere else. I am not really concerned about it being wrong as I have been using it for years with much success. But I ran across this article and thought I would ask if you considered there to be any flaws with this process and why its better or worse than the process you are describing.

     

    Here is the process I use to add components to the boot images. I used a similar script in the past for XP but exclusively have deployed Windows 7 for quite some time.

     

    Install WAIK

    create folder c:\winpe_x86

    create folder c:\winpe_x86\mount

    create folder c:\winpe_x64

    create folder c:\winpe_x64\mount

    copy C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe.wim to c:\winpe_x86

    copy C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe.wim to c:\winpe_x64

     

    Dism /Mount-Wim /WimFile:C:\winpe_x86\winpe.wim /index:1 /MountDir:C:\winpe_x86\mount

    Dism /image:C:\winpe_x86\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\WinPE-HTA.cab"

    Dism /image:C:\winpe_x86\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-scripting.cab"

    Dism /image:C:\winpe_x86\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-mdac.cab"

    Dism /image:C:\winpe_x86\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\x86\WinPE_FPs\winpe-wmi.cab"

    Dism /Unmount-Wim /MountDir:C:\winpe_x86\mount /Commit

     

    Dism /Mount-Wim /WimFile:C:\winpe_x64\winpe.wim /index:1 /MountDir:C:\winpe_x64\mount

    Dism /image:C:\winpe_x64\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\WinPE-HTA.cab"

    Dism /image:C:\winpe_x64\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-scripting.cab"

    Dism /image:C:\winpe_x64\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-mdac.cab"

    Dism /image:C:\winpe_x64\mount /Add-Package /PackagePath:"C:\Program Files\Windows AIK\Tools\PETools\amd64\WinPE_FPs\winpe-wmi.cab"

    Dism /Unmount-Wim /MountDir:C:\winpe_x64\mount /Commit

     

     

    I import these new boot images and replace the old boot images with these and distribute to the DPs.

     

    I then create an HTA and create a new package and add the HTA.

     

    I add the HTA in the task sequence very near the top right after it boots into WINPE

     

    When I make an update to the HTA I just update the DP and its available on the next PXE boot.

     

    Thanks

     

  9. I found the issue. I had given a few test machines static ip addresses to initially test installing the client. I added those IP addresses to a boundary and assigned the boundry to a boundary group. I have 2007 running along side so I have to be careful. I moved on to OSD and when I PXE booted the machine obviously got a new DHCP address (not the one I had assigned in the OS) which made it fall outside the boundary group. To resolve the issue I created a reservation in DHCP for the machines and added the addresses to a new boundary and added the boundary to a boundary group. The next time I PXE booted the task sequence worked like a charm.

     

    The static IPs were a bad idea...use reservations while testing ConfigMgr 2012 along side 2007!

     

    Mike

  10. I have been loosely following your guide and my boot images "Image ID" is referenced CAS0000x and CAS000x (where x is the incremental number) where yours was referencing P01000x. Is this OK?

     

    When I PXE boot I get "failed to run task sequence" because the boot image could not be found on the DP. I have made all the recommended settings per your guide as shown in the images. I did notice that "Update Distribution Points" was grayed out for the boot images as shown in the first image. I realized I had to do that from the CAS (difference from your pictures). I went ahead and updated the boot images from the CAS successfully but still failed to run task sequence because the boot image was not found on the DP. I actually added all four packages (two boot images, client and OS files) from the build and capture to the DP on P01 and they are in D:\SMSPKGD$. I somehow think this is related to the fact that your boot images are on P01 and mine are on the CAS. Either I did something wrong or the screen captures in your post are wrong.

     

    post-4029-0-07161700-1342552171_thumb.png

    post-4029-0-10924200-1342552172_thumb.png

    post-4029-0-22261800-1342552173_thumb.png

    post-4029-0-77312000-1342552773_thumb.png

    post-4029-0-69857500-1342552775_thumb.jpg

    post-4029-0-22524900-1342553284_thumb.png

     

    Thanks,

     

    Mike

×
×
  • 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.