wilbywilson

For Windows 2008, Windows 2012, Windows Vista and Windows 7: ports 49152 through 65535 http://support.microsoft.com/kb/832017 I had a similar failure with packages not sending to my distribution point, until I opened up those dynamic ports.

Also check this blog out: http://www.systemcenterdudes.com/?p=193

"No address found" sounds like a potential DNS issue. Can you successfully resolve/ping the DP from the Primary and Secondary servers?

Hey there, Are you 100% sure that the Active Directory System Directory is looking in the correct path/container? Did anything change recently with your AD structure? It's odd that it stopped working all of a sudden...

No, you don't need a Management Point at every location. The clients should be able to report their software/hardware inventory to the central MP, assuming everything is configured correctly (the client machines need to be in a working boundary, client settings need to have software/hardware inventory enabled, etc.) Have you looked at the "inventoryagent.log" file on a client machine?

1. I'm not sure we're on the same page. What I'm trying to say is, whether you make an app "required" and force it down to the end user with an installation deadline, or just make it "available" in the software center and the user can install it whenever they like, they do not have to be a local administrator to install it. Make sense?

Hello, 1. Absolutely, that's possible. You don't need to be a local admin for any application/package to install via SCCM. That's one of the main benefits of using SCCM to push things out. Check out this link for configuring .exe files: http://www.gerryhampsoncm.blogspot.ie/2013/03/sccm-2012-sp1-step-by-step-guide-part_20.html 2. It's tough to say how long it takes. But best practice is to make sure you can install the software on a test machine first, so you already know if the parameters work. Then, create your package/application in SCCM, but only distribute it to one distribution point, and test 1 more time. Once you're sure its working through SCCM, you can distribute/deploy everywhere. This will cut back on some of the time/trouble for those instances when you need to make changes to the configuration or content.

Shot in the dark: is this a virtual machine? I had an instance where I couldn't launch the console a while back, only to found out that the mounted virtual drive (where SCCM happened to be installed) had "disconnected" itself. We re-mounted the drive, and were then able to launch the SCCM console successfully.

I think I figured it out. It looks like the reason that the SCCM client couldn't find the SCUP patch was because the internet DP wasn't configured for "allow fallback source location for content." Shortly after checking that box, the client "switched" itself to the DP that was sitting in the DMZ, and successfully downloaded/installed the patch. Thanks.

Scenario: I've recently installed an SCCM 2012 R2 management point/distribution point/software update point into the company DMZ. Internet-based clients can communicate with this MP/DP/SUP. Hardware inventory, software inventory, and (Microsoft) security updates appear to be working. When I look at the SCCM logs, the client machines are downloading the security updates directly from Microsoft, which I believe is the expected behavior for an internet client. The issue that I'm running into is that we also intend to use SCUP to publish security updates, and that part does not appear to be working through the internet-based SUP. For instance, I've got an Adobe Flash patch that is already published/approved, and internally, this update installs fine on SCCM client machines. But on an internet-based SCCM client, it's failing to find/download the source files. (An Adobe update wouldn't be hosted on the public Microsoft update website, so perhaps that's the root of the problem.) My DataTransferService.log file shows: Downloading from http://INTERNAL_MP.DOMAIN.COM:80/Content/C8 without proxy encountered error: BITS error: 'The requested name is valid, but no data of the requested type was found. ' Context: 'The error occurred while the remote file was being processed. ' Retrying 1 times CDTSJob::JobError: DTS Job ID='{"Random Job Number"}' BITS Job ID='{"Random Job Number"}' ErrorCode=0x80072AFC CDTSJob::JobError: DTS Job ID='{"Random Job Number"}' URL='http://INTERNAL_MP.DOMAIN.COM:80/Content/C8' ProtType=1 Failed to set proxy to bits job for url 'http://INTERNAL_MP.DOMAIN.COM:80/Content/C8'. Error 0x87d00215 All proxy types and no proxy have been tried but failed. Loop the types again for the 1 time This sequence of failures goes on endlessly, since an internet-based client would never be able to reach the internal MP. So, is there some kind of workaround for this? Are other people that use SCUP facing this issue with internet-based clients? Thanks for any guidance.

I've spent the last few weeks installing/configuring a internet-based management point for SCCM 2012 R2, and I thought I'd share some tips, since it was not the most straight-forward thing. Also, thanks to those people (especially Peter) who gave me advice along the way. I chose to install the internet-based management point onto a DMZ server, which is in a separate domain from the SCCM primary. This DMZ domain does NOT need to have the schema extended for SCCM 2012, nor a "Systems Management" container created, nor add the SCCM Primary computer account to the administrators group. If you're planning to manage clients within that DMZ domain, configuring those pieces may be a good idea, but if you're just trying to stage a management point to serve clients in an existing domain, you don't need to do those steps. For configuration of PKI and certificates, I followed this post: http://sccmmofos.idepix.ca/?p=193 When installing the internet-based MP/DP, specify an account in the DMZ domain. It will need to have administrative access to the internet-based DMZ server. For the MP/DP/SUP options, choose "HTTPS", "Internet-Only", and "SSL" where applicable. You'll want to lock down the internet-based MP as much as possible. As for firewall ports: From the SCCM Primary to the DMZ Server, I opened 80, 135, 443, 445, 8530, and 8531, and 49125-65535 (dynamic range for Windows Server 2012.) From the DMZ server to the Primary, I opened up 135, 445, 8530, and 8531. (Also, in the MP settings, check the box that says "Require the site server to initiate connections to this site system." And the FQDN for the internet MP/DP should be the internet DNS name, as opposed to the internal server name.) Between the SQL server and the DMZ server, only port 1433 should be open. If you're doing SQL DB replication, also open port 4022. And finally from the DMZ server to the internet, open ports 443 and 8531. On the IIS server in the DMZ, make sure to add an SSL binding for the WSUS port (8531). The instructions I followed showed how to do this for SSL over port 443, but use the same premise to make the binding for port 8531: http://wibier.me/wsus-and-configmgr-2012-https-communication/ After all of this, your internet-based SCCM clients should be able to do hardware/software inventory, and receive approved Windows Updates. I did run into an issue with a security update that was approved/published via SCUP, but I think that may be expected behavior, and I'll start another thread on that topic. Hope this information is helpful to someone out there.

I found a Microsoft KB (http://support.microsoft.com/kb/832017) which seems to indicate that for Windows 2012, the dynamic RPC ports are: 49152 through 65535 As soon as that range of ports was opened up on my firewall (between SCCM Primary and DMZ server, the packages that were queued up started to send successfully.) Hope this information is useful to someone else.

I've been setting up a DP/MP/SUP in my DMZ, and during the setup, I opened up the firewall from intranet to DMZ (but everything is closed to the internet) to get everything installed properly. Now I'm locking things back down, but I've run into an issue where I can't distribute a package from the Primary to the DMZ distro point. Logs are showing "failed to connect to remote DP" and "Error = 0x800706BA", which based on my last few days of troubleshooting, definitely indicates firewall issues. According to the MS documentation, port 135 (both UDP and TCP) and port 445 (TCP) handle this communication. The documentation also lists RPC "DYNAMIC". So, what in the world are those DYNAMIC ports? I'm assuming it's a range of TCP ports, but I don't know the range. This is Windows 2012 R2 we're talking about. Thanks for any advice.

I think I got it figured out. If you're using/requiring SSL on the Software Update Point (as I am for this DMZ server), you have to bind an SSL certificate to port 8531. I had already bound the SSL cert to port 443 as part of the documentation on configuring the DMZ's IIS site for SSL communications, but I overlooked the SSL binding for port 8531 for the "WSUS Administration Site." Once I put that binding in and rebooted the DMZ server, I got past this error. The same IIS/SSL certificate is being used for both bindings, which works since all of this authentication is taking place on the same server (identical DNS names). Hope this info helps someone that is requiring SSL on their Software Update Point.

I've been working on installing/configuring an SCCM site server in our DMZ for the past couple weeks. I've now got the necessary certificates installed on the DMZ server (I think), as well as auto-enrolled certs the client machines. One of the last steps is to install the SUP role into this DMZ server, but I'm having problems doing that. WSUS is already installed on the DMZ server (which is fully patched.) It is configured for SSL according to the TechNet articles. However, shortly after I attempt to install the role, I see this on the SCCM Primary monitoring console: "WSUS Control Manager failed to configure proxy settings on the WSUS server" (I don't have any proxy settings configured, nor required.) I also see "WSUS Control Manager failed to monitor WSUS Server" On the DMZ server, the WSUSCrtl.log reads: System.Net.WebException: The underlying connection was closed: An unexpected error occurred on a send. ---> System.IO.IOException: Unable to read data from the transport connection: An existing connection was forcibly closed by the remote host. ---> System.Net.Sockets.SocketException: An existing connection was forcibly closed by the remote host~~ at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)~~ --- End of inner exception stack trace ---~~ at System.Net.Sockets.NetworkStream.Read(Byte[] buffer, Int32 offset, Int32 size)~~ at System.Net.FixedSizeReader.ReadPacket(Byte[] buffer, Int32 offset, Int32 count)~~ at System.Net.Security.SslState.StartReceiveBlob(Byte[] buffer, AsyncProtocolRequest asyncRequest)~~ at System.Net.Security.SslState.StartSendBlob(Byte[] incoming, Int32 count, AsyncProtocolRequest asyncRequest)~~ at System.Net.Security.SslState.ForceAuthentication(Boolean receiveFirst, Byte[] buffer, AsyncProtocolRequest asyncRequest)~~ at System.Net.Security.SslState.ProcessAuthentication(LazyAsyncResult lazyResult)~~ at System.Threading.ExecutionContext.RunInternal(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)~~ at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state, Boolean preserveSyncCtx)~~ at System.Threading.ExecutionContext.Run(ExecutionContext executionContext, ContextCallback callback, Object state)~~ at System.Net.TlsStream.ProcessAuthentication(LazyAsyncResult result)~~ at System.Net.TlsStream.Write(Byte[] buffer, Int32 offset, Int32 size)~~ at System.Net.ConnectStream.WriteHeaders(Boolean async)~~ --- End of inner exception stack trace ---~~ at Microsoft.UpdateServices.Administration.AdminProxy.CreateUpdateServer(Object[] args)~~ at Microsoft.UpdateServices.Administration.AdminProxy.GetUpdateServer()~~ at Microsoft.SystemsManagementServer.WSUS.WSUSServer.ConnectToWSUSServer(String ServerName, Boolean UseSSL, Int32 PortNumber) I don't believe it's a firewall issue (we've temporary opened things up between the Primary and the DMZ server while troubleshooting.) Any ideas on what else could be going wrong? All servers are Windows 2012 R2, SCCM version is 2012 R2 CU1. Thanks!

Thanks Peter. I'll report back with my results by next week...I'm slowly getting there.

I've run into a bit of stumbling block. I'm trying to issue 2 certificates (IIS and Distribution Point signing) to the DMZ server. This is required for the PKI implementation, which is in turn necessary to support internet-based clients. So anyway, I'm trying to issue these 2 certs from my internal CA server, but the DMZ server is in another (non-trusted domain), and I can't add the DMZ server to the "Security" tab in the certificate issuing template. How do I go about issuing these certs correctly? I thought about issuing the certificates to an internal domain machine, and then exporting them to the DMZ server, but I'm concerned about DNS and other incorrect information getting exported, and ultimately the certs not working correctly. Any tips or links to documentation on issuing certificates to a DMZ server that is in another domain? Thanks

Thanks for the reply, Peter. I will come back and update this thread as I go through the process of implementing IBCM in my environment. Hopefully my trials and tribulations will help others down the road.

Thank for you the reply, Anyweb. Given your advice, I will likely need to find a way to uninstall the pre-existing antivirus software, but I will run some tests, per your suggestion.

We're going to be bringing in some new client machines into our SCCM 2012 environment (they will be joining our domain, and getting the SCCM client w/ Endpoint Protection.) The custom client device settings are "Automatically remove previously installed antimalware software before Endpoint Protection is installed." The thing is, these clients already have an existing version (although slightly older) of Endpoint Protection. But in their current state, these clients are not being "managed", at least not the way they will be once they are within SCCM's control. So, does anyone know if these client machines will uninstall their existing Endpoint Protection version, and get the latest and greatest version from SCCM 2012 on their way into the domain? Or am I going to have to figure out a way to script the uninstallation of the "old" Endpoint Protection client before they get what SCCM 2012 R2 CU1 is pushing down? Thanks

Does anyone know the answers to these questions? For a DMZ management point that's installed in a "separate" forest/domain (which will be used to manage internet-based laptops, which already have a functioning SCCM client): 1) Do I need to extend the schema for SCCM 2012 in this new forest/domain, create a Systems Management container, and give full rights to this DMZ site server on that container? 2) Does the SCCM Primary computer account need to be an administrator on the new DMZ site server (if that's possible, give that the new site server in another forest/domain)? 3) On the existing/functioning domain, should I be adding rights for the new DMZ site server on the Systems Management container? Thanks for any advice. Chris

I'll preface this again by saying that I'm pretty new to applications in SCCM 2012, but before I updated any source files/scripts, I would make sure that the deployment is not currently active. You don't want to actively be deploying an application while the source files are in flux. After updating the source files and successfully redistributing the content to the distribution points, you can then actively target the collection that (still) needs to get the application. Within the application, you can set the "re-run" behaviors (only re-run if failed previous, always re-run, etc.) Alternatively, you could build a brand new application, and then use the new application supersedence option tab: http://social.technet.microsoft.com/Forums/en-US/1abcc581-1ee8-4929-8a2f-71c8843a257c/application-supersedence-not-working-as-i-want-and-expect?forum=configmanagerapps http://setupconfigmgr.com/application-supersedence-in-configuration-manager/ Is this putting you on the right path?

Also, if you ever stand up another distribution point (or need to rebuild an existing distribution point), you'll need to redistribute the content from your SCCM Primary. So, you definitely don't want to delete any source files from your Primary, until that particular application/package is completely retired.

I haven't played much with applications in SCCM 2012 yet, but when I updated the content of a package in SCCM 2007, I would *change* the path to the source files (then let it sit for about 30-60 minutes), and then change the path back to the correct source files location. Then, I would update all distribution points, and they would get the new content. The changing of source file path seemed to trigger SCCM to realize there was new/updated content. Not sure if this is the case with SCCM 2012, but it's worth a shot.

Thanks for the info, Peter. Do I need to do anything special with this type of setup (Management Point / Distribution Point / SUP installed on a server in a separate domain?) I do not need to manage any clients in this separate domain; I just need a functioning MP/DP/SUP which will service internet-based clients (laptops when they are off the corporate network, but already have a functioning SCCM client on the currently existing domain.) Therefore, my guess would be that I don't need to establish domain/forest trusts for this type of scenario, but then the question becomes account-related. Would I need to add the SCCM Primary computer account to the administrators group on the site server in the DMZ (is that even possible if they are in separate domains)? And in the newly created/different domain, do I need to extend the schema for SCCM 2012, create a Systems Management container, and add this new site server to it? Or should I be trying to add the DMZ site server to the Systems Management container in the current/existing domain? Lastly, is there any (good) documentation that covers the necessary ports that need to be open between the SCCM Primary and this internet-facing MP/DP/SUP? I've found some good tutorials on setting up the PKI infrastructure and required certificates, but I have not been able to find much on port requirements, nor the steps to install an MP/DP/SUP roles on a server that's in a separate domain. Thanks again for your input on this thread.