Operating system deployment slowness at remote sites.



Up until last week Task Sequence was taking approximately 9 hours to finish the image at remote sites; now it’s taking a little less than 2 hours. Below is the detailed explanation of the issue and the fix.

While checking the SMSTS.log and DataTransferService.log logs on TEST001 (Testing machine) (this one took 9 hours to finish), I found out that the packages and applications were getting downloaded from One of the Primary site (PRI01). We wanted all the packages and applications to be downloaded from Remote distribution point (RDP01) as this server is local on remote network (RN01) and has all the required packages/applications. I looked at the boundaries on PRI02 site (RDP01 belongs to PRI02) and everything was correct. I tried to redistribute packages, delete and re-add the boundary and boundary group for Remote office, but none of these fixed the issue. After struggling for a bit, I decided to check the boundary on PRI01 site. 

When I connected to PRI01 site, I realized that there was a typo for boundary IN CRP - 1. Below is the snapshot of the IN CRP - 1 boundary that I found.






As you can see here, the starting IP is 10.193.8.1 and ending IP is 19.193.11.254. This includes all the IP addresses between these two IP addresses, which includes all of our remote sites as they have IP addresses like 10.202/204/205/210 etc. Because of this conflict, the client was thinking that although it belongs to PRI02 site, its currently roaming in PRI01 site and hence was using PRI01 distribution point. After I changed the ending IP address to 10.192.11.254, the client in RN01  started downloading packages/applications from RDP01 and TS execution time went down from 9 hours to just under 2 hours.

So going forward, please pay special attention to details like this, any miss-configuration can lead to issues at some other office location.



Comments

Post a Comment

Popular posts from this blog

Enterprise CA option is greyed out / unavailable

Many times, when installing Active Directory Certificate Services they cannot choose to install Enterprise Certification Authority, because it’s unavailable as in following picture: Well, you need to fulfill basic requirements: Server machine has to be a member server (domain joined). You can run an Enterprise CA on the Standard, Enterprise, or Data Center Windows Edition. The difference is the number of ADCS features and components that can be enabled. To get full functionality, you need to run on Enterprise or Data Center Windows Server 2008 /12/R2/ Editions.  In order to install an Enterprise CA, you must be a member of either Enterprise Admins or Domain Admins in the forest root domain (either directly or through a group nesting). If issue still persists, there is probably a problem with getting correct credentials of your account. There are many thing that can cause it (network blockage, domain settings, server configuration, and other issues). In all ca
Read more

Rearm the Office 2013 installation

Image
There is a 25-day grace period from the time of installation of Key Management Service (KMS) clients before notifications to activate are displayed to the user. If you want to deploy an image, you must rearm your Office 2013 installation before you capture the image. If you do not rearm, users see notification dialog boxes at the time that the image is deployed, instead of 25 days after deployment. The 25-day grace period gives ample time for a KMS host to be found and activation to succeed. If activation is successful, users do not see notifications to activate. Rearm the Office installation Rearming does the following important tasks: Resets the grace timer to 30 days. Freezes the grace timer until either an Office application is run, or the ospp.vbs script is run. Resets the client computer ID (CMID). This is important because the KMS host uses the CMID to determine the num
Read more

MP has rejected registration request due to failure in client certificate

Image
Issue:- We have System Center Configuration Manager 2012 R2 deployed on Windows Server 2008R2 host. Recently we have moved our Certification Authority to Windows Server 2012 , renewed Root CA Certificate and intermediate Certificates also migrated Hashing algorithm from 'sha1' to 'sha2'  . New Root CA and intermediate CA also present on client machines and on SCCM. However, i have discovered these errors on MP: MP has rejected registration request due to failure in client certificate (Subject Name: ) chain validation. If this is a valid client ,  Even though Newly imaged machines are getting SCCM client installed but won't see all the client cycle under 'Actions tab' and also  'client certificate shows "None".  The operating system reported error 2148204809: A certificate chain processed, but terminated in a root certificate which is not trusted by the trust provider.  Solution:- Register  new Certificate of Root CA    under SCCM20
Read more