Jump to content


mniccum

Established Members
  • Content Count

    18
  • Joined

  • Last visited

Community Reputation

0 Neutral

About mniccum

  • Rank
    Member
  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. The user still cannot connect to the console on his/her local machine. When trying on a coworkers machine the user can connect if using the IP (not the host name). A new VM was created and the console deployed fresh and the user is able to connect. At least it's working. Looks like DNS issues. Thanks
  4. 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
  5. 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
  6. Fond another solution that I haven't tested: "When I moved C:\Program Files (x86)\Windows Imaging\ to the front of the PATH variable all started working there as well!"
  7. I was told if the console was removed from the server the WDS service would start.
  8. I found the resolution. Uninstall the console from the server and the WDS service will start. http://www.deploymentresearch.com/Research/tabid/62/EntryId/117/A-Geeks-Guide-for-upgrading-to-ConfigMgr-2012-R2-and-MDT-2013.aspx mniccum
  9. 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
  10. 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:
  11. 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
  12. 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
  13. I would still like to know why some people have to choose "copy the content in this package..." and some do not. What is the reasoning? Thanks, Mike
  14. 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
×
×
  • Create New...