When working in environments where you have multiple storage locations for your files, there are often times where you wish there were a way to centralise your data so it is always readily available. In my case, I work from a laptop computer with secondary disk with all my essential data. I also have a network attached storage (NAS) device which hosts a copy of my data. Out of the box, Microsoft Windows doesn’t offer any synchronisation tools. Enter SyncToy.
Now that we have a major new version of Adobe Reader in the form of 9.4.0, it’s time to get busy and deploy the new software to your enterprise. This article is a refresher on how best to deploy the software to your enterprise in the most effective manner.
Now that Adobe have released version 9.4.0 of their popular (and flawed) PDF viewer, it had become time for me to package the software for enterprise deployment. I stumbled across an issue with the Adobe Customisation Tool and web browser integration.
It seems there is a bug when creating a transform when setting the Allow PDF files to open in Browser option. If you set this option to enabled, once the software is deployed and you try to open a PDF within a web browser window, the following error is displayed:
The Adobe Acrobat/Reader that is running can not be used to view PDF files in a web browser. Adobe Acrobat/Reader version 8 or 9 is required."
I’m still unsure as to the exact cause of this issue, but trawling the web seems to indicate that this is indeed a result of a bug within the Customisation Tool. My workaround was to set the option to Disable and regenerate the transform. This allows you to open a PDF from a web browser but forces the PDF to open within an Adobe Reader window, as opposed to inline within your web browser.
Thanks Adobe.
I’ve been implementing Operating System Deployment with System Center Configuration Manager 2007 R2 SP2 over the last couple of weeks, with the intention of PXE booting Unknown Clients into the Task Sequence Wizard.
After running a few successful deployments, I started to notice PXE boots were failing. The PXE server seemed to be ignoring client boot requests as if they were ‘Known’ to SCCM. This was the case even after deleting the resource from the SCCM database. This behaviour was validated by looking into the SMSPXE.LOG file on the PXE server. I noticed the following lines were present.
No Boot Action for Device (17898) found ProcessDatabaseReply: No Advertisement found in Db for device
I began to investigate the PXE server configuration and noticed that after deleting the resource from the SCCM database and restarting the Windows Deployment Services service, the computer was correctly identified by PXE boot as an Unknown Computer and successfully booted into the Task Sequencer.
It seems to be the PXE server cache is causing the resource ID to remain in memory so it is no longer discovered as an Unknown Computer. Luckily, I discoverd a fix that seems to work for me. The PXE server cache timeout is determined by the following registry key. In my case, it was set to 0, which I assume is infinite. I ammeded this value to 300 (decimal) and restarted the Windows Deployment Services service on the PXE server and all seems to work as expected. I can image a bare metal computer, delete it from the SCCM database and after approximately two minutes, I can PXE boot it as an Unknown Computer again to reimage it.
HKEY_LOCAL_MACHINE\SOFTWARE\Microsoft\SMS\PXE\CacheExpire
Be warned though, I believe this is set for a reason. I’d imagine that if you are using a mandatory advertisement to the Unknown Computers collection, the machine will re-PXE boot each time the OS deployment tries to reboot as part of the OSD Task Sequence. Though this hasn’t been tested and isn’t a problem for me as I am using optional advertisements.
The following report will pull back information on all servers in your SCCM environment with disk space and volume information. It can be useful when trying to total up your disk space usage and working out where you can shed a few gigabytes.
SELECT SYS.Name, RSYS.Description0, LDISK.DeviceID0, LDISK.Description0, LDISK.VolumeName0, LDISK.FreeSpace0, LDISK.Size0, LDISK.FreeSpace0*100/LDISK.Size0 as C074 FROM v_FullCollectionMembership SYS join v_GS_LOGICAL_DISK LDISK on SYS.ResourceID = LDISK.ResourceID JOIN v_R_System RSYS ON SYS.ResourceID = RSYS.ResourceID WHERE LDISK.DriveType0 =3 AND LDISK.Size0 > 0 AND SYS.CollectionID = 'SMS000DS' ORDER BY SYS.Name, LDISK.DeviceID0
During an SP2 upgrade of a System Center Configuration Manager 2007 R2, I noticed that the installation was taking a lot longer than I thought it should. The installation screen was still active (the progress bar was scrolling along as normal) but the task had not moved on from Initialize Configuration Manager site in some time. Over two hours in fact.
Reviewing the C:\ConfigMgrSetup.log file revealed that the install had indeed stalled and the last couple of entries in my logfile looked like this.
08-04-2010 12:55:21 Enabling monitoring for inbox def Status Manager. 08-04-2010 12:55:21 Enabling monitoring for inbox def Scheduler (LAN Outbox). 08-04-2010 12:55:21 Enabling monitoring for inbox def Scheduler (Requests). 08-04-2010 12:55:21 Enabling monitoring for inbox def Data Loader. 08-04-2010 12:55:21 Enabling monitoring for inbox def Software Inventory Processor (Site). 08-04-2010 12:55:21 Enabling monitoring for inbox def Despooler. 08-04-2010 12:55:21 Enabling monitoring for inbox def Replication Manager (Incoming). 08-04-2010 12:55:21 Enabling monitoring for inbox def Discovery Data Manager. 08-04-2010 12:55:21: Status Modules\Status Modules 08-04-2010 12:55:21: Components Status Module: SMS Server\Components 08-04-2010 12:55:21: Components Status Module: SMS Client\Components 08-04-2010 12:55:21: Components Status Module: SMS Provider\Components
After some research, I discovered that the reason this was occurring was I had a huge collection of .CCR files within the ccr.box folder on my site server. When I say huge collection, I mean over a million files. After deleting them all, which took around 30 minutes, the installation jumped right to the next stage.
It’s worth noting, the .CCR files were actually in a sub-folder of ccr.box, so I’m assuming that SCCM SP2 update searches for all .CCR files in the complete ccr.box folder hierarchy.