cgbolton1

Ok so I am not trolling this thread after getting my Configuration Manager current branch 1702 with the May updates installed to actually PXE Boot (I talked about that in another thread) but now I am dealing with incredibly slow speed to boot up. I don't even know how well the thing will handle the TS because it takes so long to actually boot the WIM file for the image build. I am pulling the file from a server at another site but we have a very large pipe and I can easily transfer multi-gig files in a a very short time. The WIM file for WinPE5 can't be that large but it is dragging on for about an hour. I have messed with the TFTPWindowSize, the RAMDiskSize the MAXBlockSize (which is what allowed it to work and not timeout) but nothing seems to make a big difference. I am not sure if there is a log that I can look at or if I have to resort to packet tracing but I desperately want to get this issue resolved so I can move forward again. Any help would be greatly appreciated! Thanks, Chris

I found my issue after a ton of searching. This thread (https://social.technet.microsoft.com/Forums/ie/en-US/a1246f62-6a8a-482b-9323-7e02dfeab196/wds-tftp-errorcode-1460?forum=winserversetup) had the answer. I was getting a TFTP error 1460 which is a timeout and it turns out that a limitation in the block size for files being transferred via TFTP was what caused my issue. This seems like the kind of thing that others would run into so I will post the actual change. On the PXE Boot DP/MP you need to make a change to the following registry key and then restart the Windows Deployment Service in the Services MMC snap in. Location:HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\services\WDSServer\Providers\WDSTFTPName: MaximumBlockSize Type: (REG_DWORD) Value range: 512–1456 Base: (Decimal) I have experimented with 512 and 1024 block sizes and they both seem to work however my guess is that 1024 will produce faster results when imaging. I am pulling my first image for Windows 10 using PXE Boot but unfortunately I don't have a local DP setup to handle the files so the whole process is being strung out through my WAN. I hope to get a test DP in my location later today so that further testing can move along much faster.

I am stuck on PXE-E32: TFTP open timeout error. I have been following all of the steps listed as I setup my new CM 1702 and everything seems to be working but I cannot get PXE Boot to work. I double checked that option 66 and 67 are set on the DHCP server and that there isn't a firewall blocking. I even went so far as to install a graphical TFTP client on both my own workstation as well as on the server. I attempted a simple GET command and it results in a connection failed. Something seems to be blocking TFTP but there isn't much to go on. The SMSPXE log seems to indicate that WDS is starting properly so TFTP should be starting with it and TFTP seems to be the only thing listening on port 69 of the server. Is there anything else anyone can suggest for me to check? Thanks, Chris

Ok so I have been battling with getting Reporting Services running for a while. It was originally running on my CA but then it stopped and I received errors when I attempted to run reports. I don't have the original errors anymore but when I tried to reinstall the role the result is that reports don't populate in the console and then I get a string of folder that are created at regular intervals on the SSRS site (ConfigMgr_XXX.OLD.#) and then just go on and on unless I remove the role. Several people have told me to reinstall my CA but I think there must be something easier. Any input is appreciated. CB

I cannot tell you how many times this has happened but moments after posting my question I found the answer. I went into the reporting web site and checked the permissions for my administrator accounts and low and behold the administrator accounts did not have the appropriate permissions to view the reports in the browser or the console. I made the changes to permissions and now I can see historical data populating in reports for the past 3 months! The moral of the story is to take the time to document and review all the steps you have taken to resolve the problem so you can more easily discern where you might have skipped steps. V/r, Chris Bolton

I am stuck and I need a bit of assistance as to where to go next. I have a CM12 hierarchy system setup with a CA and a PSS (and a few DP site servers). I am trying to get software metering reports to work and cannot seem to get them to populate with data. It appears that data is being parsed into the SQL database on the PSS because I can query the associated tables in SQL Management Studio and see that data in views such as v_GA_SoftwareUsageData but whenever I run any of the web reports I cannot select dates or software items. I have forced summarization by running runmeteredsumm.exe on the PSS (which hosts it's own SQL server) and I get a response that "Monthly Usage Summary added 105 rows in 1 seconds" so it looks like the data is being retrieved and stored. The CA is running the Reporting Service Point and it seems to run other reports without issue. I have checked and re-checked that my client policy that enables software metering is setup correctly and deployed to all systems. It is set to collect data every 7 days. I also checked that I have metering rules enabled and also that automatic rule creation has been enabled and it is set to create rules but leave them disabled. I have 8 rules enabled to monitor Microsoft Office, Adobe Acrobat and Autodesk AutoCAD. I could run queries in SQL Management Suite to get the information I am looking for but I would prefer to use the reports web site to allow management to easily retrieve reports. I had this working on CM12 SP1 (so I feel like I have a clue about how to configure this feature) but when we did a fresh install of R2 and configured the feature the same way, it just won't seem to work. I have found this site to be an invaluable resource so I am hoping that someone here will have some further insight or suggestions. I would be happy to post any of the server or client log files if these would help discern the answer to my challenge. Thanks much! Chris Bolton

I am working on a lab installation of SCCM 2012 on Server 2012 with SQL 2012 and I am experiencing similar issues with high CPU utilization on my Primary Site server. The servers all live within an ESXi 5.1 environment. Here is the basics: SCCM-CAS - 2CPU, 8GB RAM, thick provisioned hard drives - Server 2012, SQL 2012 (with memory max and min set to 8192MB) SCCM-P01 - 2CPU, 8GB RAM, thick provisioned hard drives - Server 2012, SQL 2012 (with memory max and min set to 8192MB) Both of the servers were originally configured following the lab recommendations on this web site when configured with SQL 2008 however I was able to get SCCM 2012 SP1 and SQL 2012 with CU 2 installed and functional (except for this problem). I was initially experiencing high CPU utilization on both of the servers so I started experimenting. The first thing I did was to change hard drive provisioning on SCCM-CAS from thin to thick (no discernable impact on performance). Then I added 2GB of RAM on to of the origionally configured 4GB for a total of 6GB and there was a small improvement. Finally I added a second CPU (for a total of 2) and things started to improve. The impact wasn't immediate but after about an hour SCCM-CAS improved to the point where CPU utilization runs between 10-20% when I am not doing anthing and bumps to about 50% when I start working in Configuration Manager Console. With the improvements to SCCM-CAS I thought it would make a difference on SCCM-P01 if I implemented the same changes. It has been a day since I changed SCCM-P01 to match SCCM-CAS and there hasn't been an improvement in performance. As a result of the high utilization SCCM-CAS reports degredation with regard to replication. It appears that the SQL instance on SCCM-P01 is what is causing the high CPU utilization but I am not quite sure what I should do about it. My testing and deployment has ground to a stand-still because of this high CPU utilization issue. I could add yet another CPU to the SCCM-P01 but I am thinking there is some other issue. Any insight into this would be greatly appreciated. Thanks, Chris Bolton Edit: I went ahead and added 2 CPUs to my SCCM-P01 and now it is running like a champ. I am still not sure why it requires so much horsepower but replication is working properly now and all seems well. Now I have to figure out why I can't get the CAS to download updated. I get "Access denied" on the download attempts but that is a discussion for a different forum.

I actually have a strange issue going on. I am using the XP to W7 Demo TS as my template for hardlink USMT however during the process the XCOPY command seems to be trying to copy the entire contents of my distribution point to the client. The command I am executing is as follows: xcopy * %systemdrive%\USMTbits\X86 /herciy I am also including a package that includes the x86 folder of the USMT folder in the "Run Command Line". What I was expecting to happen was that the contents of the package should be copied to the %systemdrive%\USMTbits\X86 folder, not the entire contents of my DP. The result is that the TS takes a huge amount of time and fills the drive of the client workstation. I am going to poke around and see if I can use a batch file to copy the USMT files and the runscanstate batchfile. If anyone has any ideas on how to fix my xcopy problem and to limit what xcopy is copying I would appreciate it.