KuifJe

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.

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).

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.

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.

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

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.

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?

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.

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)?

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.

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?

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.

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

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?

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?

I tried this for a fresh deployment of a new system, however after booting into WinPE it would exit with no error code. Instead it says there's no Task Sequence available for this machine. I then removed the checkmark and everything worked perfectly. This was with a virtual machine on Hyper-V.

That's as complicated as it can get I guess. In our case SQL and SCCM would both be plugged into the same 1Gb switch so data throughput (normally) shouldn't be an issue. My main reason to use a seperate (dedicated) SQL server is because we're thinking of virtualizing the SCCM server itself and we want to seperate functionality as much as possible. Thankfully we have a sh!t hot AD admin (me!) ;-) K [edit] This is from the official Infrastructure Planning and Design guide provided by Microsoft: Also: So I guess the virtual path is out of the window. [/edit]

Quote from another post. Why is this not recomended, in my mind it's best to seperate database and application to ensure optimal performance? K

Looks good to me Especially the main site with the news items is a lot better! Keep up the good work, I'll have a look for a nice logo...

yep, that's better

Shame I updated all the servers before I started the install of SCCM

I was wondering about this... This would mean you'd also have to disable an in place WSUS policy? So you don't need to configure a policy to check for updates on the WSUS, rather you shut down the updates all together and rely on the SCCM agent for regular checks?

If I browse to http://windows-noob.com I end up with the linux noobs EEEEW!

Quick explanation of my test lab: - 2 primary SCCM sites up and running (ABC and XYZ) with little to no problems - I have a functional PKI infrastructure connected to the main site (ABC) - I'm trying to link both sites in a parent - child setup (both primary sites) primarily to get the reporting of site XYZ to site ABC. - Keys for both sites have been exchanged using the preinst /keyforparent and /keyforchild parameters. The questions I'm struggling with: - Can I use the PKI infrastructure from the ABC site to configure the XYZ site with the required certificates or can I use a seperate PKI environment from the XYZ site? - What ports will be used between both sites? I've been ploughing through countless of Technet articles but haven't found a clear answer yet except that SMB is used for site to site communications. - I'm getting both DNS and NETBIOS errors when configuring a new adress. When I configure the adress with a FQDN I get an error stating NETBIOS name resolution is failing and when I recreate the adress with the NETBIOS name I get an error stating the server cant find the FQDN. Bright ideas and suggestions are all welcome

Solved! I messed up with DHCP configuration apparently. I only configured scope options and removed the server options in the DHCP server. After reinstalling the DHCP scope and leaving all the options as standard it all went flawless! Next step ... native parent - child configurations... Any nice and graphically explained tutorials somewhere