according to an article by Microsoft the following is true of software updates when they are used in sccm 2012 r2:

Important

You must manually create the shared network folder for the deployment package source files before you specify it in the wizard. Each deployment package must use a different shared network folder. does this mean that i have to create a huge number of actual shares or just one shared folder with multiple subfolders which each correspond to a single update? i'm slightly confused with the way sccm does updates and thus need some advice. i currently have about 400+ updates that are visible on the console, but i have not downloaded them yet. do i download them individually and then package each one? do i simply put them all in one big deployment package? any advice will be highly appreciated. my main aim with this server is not so much to deploy updates to our network, but more to point my customsettings.ini file to so that my reference machine can pull updates locally instead of from the internet.

No, you need to create a folder on a network share that you will use for your deployment package. The sub-folders for the updates, those folders with GUIDS, will be created automatically when the updates are downloaded to the deployment package.

thanks. so in terms of the deployment package should i package multiple updates etc...in essence i need to understand how one decides what to put into a deployment package. or is it entirely up to you what and how many you put in there?

That's completely up to you. For example, if you deploy Windows 8.1, you can put all the Windows 8.1 security patches in the deployment package.

A deployment package is distributed to the distribution point and is used by the clients as source location for their required updates. So, the updates that you deploy via a software update group should always be a member of a deployment package.

"my main aim with this server is not so much to deploy updates to our network, but more to point my customsettings.ini file to so that my reference machine can pull updates locally instead of from the internet."

Sorry, this statement doesn't make sense. Are you building your images with stand-alone MDT? Even so, how would you point it to a bunch of random files to install updates?

ok. to clarify read my explanation below:

i recently installed a software update point role in sccm 2012 r2 and synchronized about 419 updates. none of them are reported to be downloaded except the office 2013 service pack 1 update for which i specifically created a deployment package. no update groups have been created.

in light of this i find it strange that under "all software updates" the column that reads "required" and "installed" contains numbers in them (2 in my case) as if i have machines that are already pulling and installing these updates? i have made no deployments to any collections? this freaked me out so i went and turned off the section on the client settings package that reads "enable software updates on clients" (under software updates category).

i'm worried that i have read the ms information incorrectly somewhere, since i was under the impression that i have to deploy updates first before they will install?

firstly, does the software updates section in client settings package turn off the ability of clients to do windows updates or is it for something else? secondly, could this have been a reference machine i was building using mdt where i specifically pointed to the update server in the customsettings.ini file? (i did this after the catalogue synched for the first time). was trying to get the mdt build to pull updates from the sccm sup instead of the internet, but later found out that i first have to download the updates.

any ideas?

Update compliance in the console has nothing to do with updates downloaded or deployed. Clients scan against the update *catalog* and return their compliance results.

"does the software updates section in client settings package turn off the ability of clients to do windows updates or is it for something else?"

Not exactly sure what you mean, but no. ConfigMgr simply leverages the Windows Update Agent to scan for update compliance and install updates. The ConfigMgr agent control the WUA (although the WUA is still fully functional which is why we generally recommend that you disable automatic updates via a GPO).

"could this have been a reference machine i was building using mdt where i specifically pointed to the update server in the customsettings.ini file"

Pointing to an update server is different than pointing to a set of files. MDT can absolutely be configured to use a WSUS instance, however, when integrated into ConfigMgr, a WSUS instance does not (or at least should not as it would be redundant and useless) download content thus pointing MDT to a WSUS instance integrated into ConfigMgr would have no effect. You can't simply point MDT at a set of downloaded files though.