Jump to content




KuifJe

Established Members
  • Content count

    31
  • Joined

  • Last visited

Community Reputation

0 Neutral

About KuifJe

  • Rank
    Advanced Member
  • Birthday 05/27/1976

Contact Methods

  • Website URL
    http://
  1. Hi, I'm trying to deploy an application targetted at a user-based security group. Everything is showing up fine in the application catalog but when I start the installation the deployment fails with the error message: 'The requested operation requires elevation' In SCCM 2007 there was an option to run with elevated rights, but I can't seem to find this option in the SCCM 2012 applications. Any hints or tips would be appreciated.
  2. Yes, it only gets the updates it needs. Updates will not be downloaded untill the installation of the updates is started. The installation can be started manually or you can use a deadline in the deployment settings of the update package. Do you get the popup of the SCCM agent which says there are updates available? Also check your deployment settings (Computer Management > Software Updates > Deployment Management) when the updates will be made available to the client. Attached is a screenshot of the settings for a deployment package from my environment (which works perfectly).
  3. The SCCM client will start a scan for updates and compare the ones installed to the ones needed/available just like with a regular WSUS. After the scan it will only download the updates when needed by the client. The download will not start untill the deadline for the updates has been reached and even then it depends on the different settings in the update deployment package. You can check the UpdatesHandler and UpdatesStore log files of the SCCM clients to see if there was an update scan and if there were any updates available.
  4. You can use a GPO to configure the 'Specify intranet Microsoft update service location' to point to the SCCM update point. This would prevent users from changing the setting. This would however override the SCCM client setting, so when changing the SCCM update point you will need to manually adjust the GPO to point to the new update point.
  5. Sorry, missed the bit for Client Installation. However, I would still refrain from using a GPO to configure the WSUS/SUP location. Instead, define the proper discovery methods (AD System Discovery) and make sure you're discovering all systems you want to manage with SCCM and then configure the Client Push Installation method (http://technet.microsoft.com/en-us/library/bb632380.aspx). This prevents any conflicts between local policies set by teh SCCM agent and the GPO that wsa used to direct the systems in the first place. Also, with the client push installation you can control additional settings for the SCCM agent (SMSSITECODE, SMSCACHESIZE, CCMINSTALLDIR etc.). More info: http://technet.microsoft.com/en-us/library/bb680980.aspx
  6. In theory that would work, however, there's no point really. If you let the SCCM agent manage this setting you wouldn't have to use a GPO, which in turn would save the computer on boot up time since it wouldn't have to process an extra (unnecessary) GPO at boot.
  7. Simple question really. What's the difference between an update with a set bulletin ID (say MS10-xxx for a 2010 update) and no bulletin ID?
  8. It sounds like a plausible workaround to me. Just make sure you've got your boundaries in SCCM configured and/or maybe prevent automatic SCCM agent installation by disabling all client installation methods.
  9. Remove either the SCCM or the SCE agent would be my advise and stick to 1 application for desktop management, or, as anyweb pointed out, decide which functionality you want from which application. SCE uses the same mechanisms and communication channels as SCCM so it's hard to troubleshoot. It might even be possible SCE agents are responding to SCCM policies. Not to mention SCE using group policies which could overwrite certain local policy settings used by SCCM. What is the exact reasoning behind using SCE and SCCM in the same environemnt (if you don't mind my asking)?
  10. If your update package has a deadline that's set in the future it will indeed wait with the installation untill after the deadline. You can choose to install the updates manually from the server or adjust the deadline of the update package.
  11. Hi there, I have a Windows Server 2008 R2 task sequence running flawlessly. Installing applications and App-V packages, adding to the proper domain and OU. Recently we created a script changing some settings with powershell. To be able to run this script in the tasksequence I'm trying to change the execution policy to 'unrestricted'. We have a policy in place to change the execution policy to 'RemoteSigned' but this policy is applied at the end of the tasksequence. To change the policy I've added a command line entry in the task sequence with the following command: cmd /c Powershell.exe -Command Set-ExecutionPolicy Unrestricted This command works properly when I run it from a CMD prompt, however it has no effect when run during the task sequence. I've browsed through the SMSTS.log file and I see the commandline being built and called with the smsswd.exe tool, it seems to run properly and finish as it should, but after checking the policy setting in Powershell it's still on 'Restricted' Any thoughts or ideas?
  12. Task Sequence and Powershell

    The script is at the root of the package. The eventual error I got is 0x80070001 which is a file missing error (IIRC). This led me to believe the command wasn't executed directly from the package dir but from System32 or somewhere else. I reconfigured the package to include the complete path to the script (C:\_TaskSequence\etc..) see if that works.
  13. Task Sequence and Powershell

    It's a package. The TS is configured to download packages before they are run. The script itself will adjust the Execution Policy to RemoteSigned so it can execute local scripts. edit: spelling
  14. Task Sequence and Powershell

    Hello all, I have an OSD task sequence deploying Windows Server 2008 R2. All is well, SCCM client gets installed, SCOM agent gets installed, drivers get injected. Now there's also a Powershell script which fails with errorcode 1. For the life of me I haven't found a clue as to where the problem lies. Running SCCM 2007 SP2 R2. The scripts is packed inside a program which will call the following commandline (as administrator): "%windir%\SysWOW64\WindowsPowershell\v1.0\Powershell.exe" -command ".\Script.ps1". Manually running this command in a powershell prompt everything works. I've also incorporated a sytem reboot to the new OS in the Task Sequence so the powershell execution policy gets set to "RemoteSigned" and the program is also copied locally before execution... Any ideas anyone?
  15. Good to see the guide is still functional even after all the R2 versions (2008 and SCCM) and SP2 release. Just one quick question about setting up software updates... This says I have to redownload the updates from the internet when creating the update deployment, wouldn't it be wiser to just use the files downloaded by the initial synchronization of the server?
×