Jump to content


Established Members
  • Content Count

  • Joined

  • Last visited

Community Reputation

0 Neutral

About mniccum

  • Rank
  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
  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 in
  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.ManagementObjec
  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 an
  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 t
  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-0050
  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 Filen
  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
  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 tim
  • Create New...