In the web gui for OSD, there is an option to set the TFTP Blocksize. Tuning this value leads to much better download speeds when initiating a bare-metal deployment. I’m looking to find a way to report the current value in an Analysis. Where does OSD store this configuration? I haven’t located it in the Registry, rembo.conf, etc. yet.
If it’s stored in the SQL database, can anyone provide a query to retrieve it and point me to where I can retrieve the SQL credentials?
Hi Jason,
you can look into
hklm/software/( if 64bit Wow6432Node)/BigFix/EnterpriseClient/OSDTftp/currramdisktftpblocksize_
registry key on bare metal server.
Simlar path for window size
Hope it helps
Regards
Alessandro
I don’t have the OSDTftp registry key, though I’ve changed the value in the Web GUI. The only OSD key beneath EnterpriseClient is OSDControl, which has 5 values for SyncTime (SyncTimeManifest, SyncTimeMedia, SyncTimePE10, SyncTimePE3, and SyncTimePE4).
I don’t see anything related under HKLM\Sofware\Wow6432Node\BigFix\ProxyAgent\Settings or HKEY_LOCAL_MACHINE\SOFTWARE\Wow6432Node\BigFix\Management Extender\Bare Metal Extender either.
Hi Jason, there is three different TFTP parameters you can tune, as described in
http://www.ibm.com/support/knowledgecenter/SS63NW_9.5.0/com.ibm.bigfix.lifecycle.doc/Lifecycle/OSD_Users_Guide/c_tuning_tftp_settings.html
“Max TFTP Segment Size” , that you set in the “old” TPMfOSd webui, acts at tftp server level. This setting currently cannot be set, nor queried, via BigFix. We are working to make this available.
The two parameters that act at WinPE TFTP client level:TFTPWindowSize and TFTPBlockSize can be set from BigFix via Task 360 in OSD site, and can be queried via the registry keys mentioned above.
Please note that the registry keys are created the first time Task 360 is run. So, before it has ever been run, the two parameters have default values and the reg keys are not present.
Thanks
Alessandro
The note on Task 360 is helpful, thanks, I’ll be looking in to that next.
The block size is going to be bound by what the server allows, so I’ll still need to tune the server-level Max TFTP Segment Size. I understand there’s not currently a task available to query or set this in BigFix. But I’m already using BigFix to manage a lot of things that don’t come “out-of-the-box”, this forum’s all about custom authoring.
The server-level Max TFTP Segment Size must be stored somewhere. I’m just looking for some help finding it. Is it in a .conf file, a .ini file, a table in the SQL Express database, or somewhere else ???
Jason, I get what you’re saying.
Unfortunately this info is stored in a proprietary db file on the bare metal server, that cannot we queried unless we export it to some other form (as you say, ini file or registry key or so).
So, this is the enhancement we are working on - allow to set/get some bare metal server properties (tftp segment size/debug level and a few others) in the BigFix world.
We’ll keep you posted
Best regards
Alessandro
I had come to the same conclusion myself, I can see from procmon that server.db is what’s being updated, but I couldn’t figure out whether it was a database format that I could use.
So is the enhancement to give individual fixlets/analysis to deal with the existing proprietary database, or to migrate the database function to something we can query ourselves (access, sqlite)? If given an option, I’d think a database format that we users can examine would be better for recovery and configuration management.
Most likely we’re going to export the proprietary db relevant info into a file or a registry key, in this way it can be queried both by out-of the-box features and by custom content
did this ever become a thing? we were discussing this configuration earlier and it looks like the initial / default settings are still not visible in a registry key. It’s really helpful to be able to defer to the default or currently set values before changing it. before/after comparisons, or rollback options etc… 
.
(while we wait on an Official Answer…)
I’ve observed that there is a file being created. I think it’s coming from the OSD Management Extender plugin, but can’t really be sure; in any case it’s less than a minute old on each of my servers so I think it’s generated frequently.
On the Bare Metal Server, at c:\TPMfOS Files\global\tem\baremetalsettings.conf. Looks identical to the file that would be generated by an ‘export configuration’ command from the TPMfOSD web interface.
We were discussing TFTP segment sizes in the other place, my value from this file is
MaxTFTPSegSize 1468
What I don’t know is … whether that’s internally used as a “Block Size” (max size per packet) or “Segment Size” (max amount of data transferred, in multiple packets, before waiting for an ACK from receiver). I suspect the first but don’t have a network capture to back that up (yet).
Also, per the earlier note on finding the WinPE TFTP settings, I’m actually finding that under HKLM\Software\BigFix, not HKLM\Software\Wow6432Node\BigFix on my 64-bit hosts.
@alexdinia, if we clear the registry entries for curramdisktftpblocksize_X and curramdisktftpwindowsize_X, does TPMfOSD have a default value, or does it just leave these unconfigured and use whatever are the Microsoft defaults for the bootloader?
Hi Jason,
I’m investigating…
Hi Jason,
yes, the baremetalsettings.conf file is generated every minute and is an export of the Bare Metal server configuration.
About the ‘Max TFTP segment size’, it is the maximum size of the TFTP segments, that means the ‘Block size’. But ‘Max TFTP segment size’ is a limit set at Server level, the ‘Block size’ is a value set at client level, a parameter that the client provides when negotiates the communication.
The registry entries should not be edited. Using the BigFix console, they rapresents the parameters of the ‘Edit settings for computer’ panel of the Bare Metal Computer.
If these settings are deleted the Microsoft defaults will be used. It has to be applied just the limit set for ‘Max TFTP segment size’.
I think that actually answered my questions, thanks very much! The main point is that clearing the registry entries for curramdisktftpblocksize_X and curramdisktftpwindowsize_X should cause the WinPE image download to use default values; so clearing those registry keys should be a safe way to go back to defaults. We don’t need to know or preserve the Microsoft defaults in order to set them back after testing.
Another follow-up on this point.
The Bare Metal Server is set with
Max. TFTP Segment Size 1468
Based on Task 360 “Bare Metal WinPE Tftp settings” I’ve configured my WinPE ramdisk with
ramdiskTftpWindowSize 32
ramdiskTftpBlockSize 32678 (which, by the way, is probably a typo in the options - shouldn’t that be 32768 ?)
Based on a packet capture, the Task 360 version of ramdiskTftpBlockSize is mostly ineffective - the transfer is limited to the ‘Max. TFTP Segment Size’ applied at the bare metal server:
(client to server) TFTP 104 Read Request, File: \sources\boot.wim, Transfer type: octet, tsize=0, blksize=32678, windowsize=32
(server to client) TFTP 87 Option Acknowledgement, tsize=387199486, blksize=1468, windowsize=32
Notice the server does not acknowledge blksize=32678; instead the server pulls that down to 1468, the max value configured on the OSD server pages.
When I increase that value on the Bare Metal Server pages, I get a lot of “Fragmented IP” packets in the sniff, very slow download at the client, and the client bluescreened before getting the entire WinPE boot image. I tried at values 16384 and 4096.
So, it appears that the OSD page for “Max TFTP Segment Size” value corresponds RFC 2348 TFTP Blocksize Option, as does the Task 360 option for “ramdiskTftpBlockSize”. And the Task 360 option for “ramdiskTftpWindowSize” controls the value of RFC7440 “TFTP Windowsize Option”
Most of the postings I see on increasing TFTP performance in Microsoft’s Configuration Manager involve setting RamDiskTftpBlockSize as high as 32768, and from what I can tell the default value in Configuration Manager version 1606 is 4096 bytes. I’m not sure why I’m crashing with that value, whether it’s a limitation of the Rembo TFTP server, or maybe some of my traffic-inspecting gear in the way (which is plausible given the IP fragmentation).
I think it’s important though for us to know that whatever value we specify in the Task is going to be limited by the Bare Metal Server’s ‘Max TFTP segment size’ value so we don’t burn time experimenting down that path.
Are there any other performance settings available that I might be missing?
Jason,
Did you ever get this solved?
I’m experiencing terrible tftp perfomance, more than one hour to transfer the .wim file. Have tried Task 360 to set blksize to 16384 and windowsize to 8, but it seems like only windowsize is honored:
[2018/09/10 12:47:34:770] (tsize) option 0 TFTP (27)
[2018/09/10 12:47:34:770] (blksize) option 16384 TFTP (17)
[2018/09/10 12:47:34:770] (TFTP) block size is 512 (7) on ‘192.168.16.113’
[2018/09/10 12:47:34:770] (windowsize) option 8 TFTP (0)
[2018/09/10 12:47:34:770] (TFTP) windows size is 8 (15) on ‘192.168.16.113’
This page says that I should use the Tivoli Provisioning Manager for OS Deployment WebUI to set the Max TFTP Segment Size accordingly, but I’m not able to log in to the WebUI with any know credentials.
https://www.ibm.com/support/knowledgecenter/en/SS63NW_9.5.0/com.ibm.bigfix.lifecycle.doc/Lifecycle/OSD_Users_Guide/c_tuning_tftp_settings.html
Any hints?
Regards,
Harald
The block size you define in Task 160 is still limited to the maximum block size defined in the Web Interface.
The password used in the Web Interface is set when you first install the Bare Metal Server.
I have a Custom Fixlet that I use to configure the properties, this should be helpful as you can set it without logging in to the web interface. My settings wouldn’t be helpful for you, but try running the following in the Fixlet Debugger on the Bare Metal Server:
AGENTFOLDER:
Q: following text of first "%22" of preceding text of first "\rbagent" of (value "ImagePath" of key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemboAgent" of registry as string)
-> This gives the path the REMBO Agent Folder
DATADIR:
q: value "DataDir" of key "HKEY_LOCAL_MACHINE\SYSTEM\CurrentControlSet\Services\RemboServer" of registry as string
The AgentFolder path contains a rembo.conf that gets updated by the Bare Metal Proxy Agent, once a minute I believe. The bare metal proxy retrieves this from the Bare Metal Server database (which we cannot read directly). One of the parameters in the conf should read something like
MaxTFTPSegSize 1432
You can create a new rembo.conf file, replacing the existing MaxTFTPSegSize with your value. Stop the remboserver service, and then import the new file via
rembo.exe -d -v 4 -c “path\to\new\rembo.conf” -exit
An exit code of either 0 or 99 both seem to show success.
After that, start the remboserver service again and the new tftp max segment size should be in effect.
The rest of this post should be used with caution. I only did it once and haven’t built a procedure, I’m working from memory and may have forgotten a piece.
While you’re in there, note that there is a “NetPassword” value in the rembo.conf as well. That is some kind of hash of the password you set at installation time. You could install a new temporary Bare Metal Server elsewhere, using a known password; then take the hashed password out of that new server’s rembo.conf, and add it in to your real server and import the file same as above to reset the password.
There is another config file on the bare metal server, rbagent.conf, that’s used in building the WinPE resources I believe. You’ll need to update the password in that file to ensure the client matches the server password when it bare-metal boots, and you will probably need to recreate your Deployment Resources to use the new password.
Jason,
Again, thanks for answering 
The problem is that I never was asked for a password (or userid). Here’s a copy of the dialog from installation time:
The userid and password in the last dialog box was for the local admin in order to log in to the relay server, but if I try that it just says “Invalid login”. I guess this is maybe caused by the fact that the User ID gets truncated like this:
Based on the discussion earlier in this thread, I found the file c:\TPMfOS Files\global\tem\baremetalsettings.conf which is updatet once a minute. This contains the setting “MaxTFTPSegSize 512” which corresponds to what I see in the logs when I up the log level.
The rembo.conf file in the path returned by your first Q: doesn’t have an entry like that.
Is it a (modified) copy of the “rembo.conf” or the “baremetalsettings.conf” that should be used as input to “rembo.exe -d -v 4 -c “path\to\new\rembo.conf” -exit”?
Regards,
Harald
To elaborate, the “rembo.conf” file contains this:
BaseDir "C:/Program Files/Common Files/IBM Tivoli"
DataDir "c:/TPMfOS Files"
NetPassword “E7F6E0B59CE0522A6FD1ECD902E529BA”
#Interfaces ipaddr1 ipaddr2
#DisableSSL
HTTPAdminName "NO00999C21B588\administrator"
HTTPServerPort 8081
HTTPSServerPort 443
DefaultGroup "Default"
DefaultStartPage "net://global/rad/bootcode.pak"
DefaultOptions KernelFree,AutoBoot
Behaviors 7
HTTPRoles Administrators {
Members "Administrators"
AllowPages “"
AllowGroups "”
}
HTTPRoles Operators {
Members "Operators"
AllowPages ""
AllowGroups ""
Policies “CONF_RO”
}
Tunnels ODBC {
RemoteHost "localhost"
RemotePort 2020
}
and the “baremetalsettings.conf” contains this:
BaseDir "C:/Program Files/Common Files/IBM Tivoli"
NetPassword "E7F6E0B59CE0522A6FD1ECD902E529BA"
GlobalDebugLevel 3
LangID 0
Backup 0.0.0.0
MaxLogSize 0
MaxLogNumber 0
CountersInterval 5
#Interfaces 127.0.0.1
TaskTrackMinFiles 2
TaskTrackFilesAge 168
Behaviors 7
RelayDownloaderTimeout 60
#IgnoreSnAndUuid
RefreshHostFreq 1
StartPageTimeout 5
HostDeleteMax 100
HostDeleteAge 12
HostDeleteFreq 0
SwitcherMessage ""
CriticalModels “”
#BootAfterStartup
#DisableBOOT
#DisableDHCPProxy
#BootNoMulticastDiscovery
TFTPPort 69
MTFTPStartDelay 2
MTFTPClients 232.1.0.1:8500
MTFTPPort 4015
BootReplyDelay 0
BootReplyLimit 0
BootDiscoveryPort 4011
BootDiscoveryAddress 232.2.0.1
DisableBootSchedule ""
DisableBootDuration 0
MaxTFTPSegSize 512
#DisableNBP
NBPServerPort 4012
#DisableFILE
DataDir "c:/TPMfOS Files"
SharedDir "shared"
FileMCASTAddress 239.2.0.1:10000
FileMCASTAddrCount 256
FileServerPort 4013
CachedIdx 64
FileMaxPCASTSessions 264
#DisableWideMCAST
#DisableTCP
#DisableHTTP
#DisableSSL
HTTPServerPort 8081
HTTPSServerPort 443
HTTPAdminName "NO00999C21B588 dministrator"
HTTPSessionTimeout 3600
#DisableContextualMenu
#DisableBottomLeftMenu
#DisableChecklistPage
#DisableDragAndDrop
#DisableJsButton
#DisableJsDropDown
#DisableGlossary
#DisableCookies
#DisableHTTPOptim
#DisableBobTheBulb
RESTPassword “BiGrTnU7i8o3”
#DisableSlaveWarning
HTTPRoles ADMINISTRATORS {
Members "Administrators"
AllowPages “"
AllowGroups "”
#Policies …
}
HTTPRoles OPERATORS {
Members "Operators"
AllowPages ""
AllowGroups ""
Policies “CONF_RO”
}
Tunnels ODBC {
RemoteHost "localhost"
RemotePort 2020
}
DefaultGroup "Default"
DefaultStartPage "net://global/rad/bootcode.pak"
DefaultResolution "800x600"
DefaultAuthDomain ""
DefaultOptions KernelFree,AutoBoot
#DefaultPXEBootMode …
#DefaultFileServer 0.0.0.0:0
#DefaultLockout …
#DefaultRemoteConsole 0.0.0.0:0
Harald
I’ve done some experimenting in my VMvare lab environment and ended up with this command line (after stopping the rembo service) and adding the MaxTFTPSegSize setting to a copy of rembo.cfg:
C:\Program Files\Common Files\IBM Tivoli>rembo.exe -d -v 4 -c “C:\Program Files
Common Files\IBM Tivoli\rembocopy.conf” -exit
Bootable: \.\PHYSICALDRIVE0
Bare Metal Server for IBM BigFix OS deployment server 64 bits v.7.1.1.20 (310.11
)
Licensed Materials - Property of IBM. L-PSCN-7SXJVW
© Copyright IBM Corporation 1998, 2018.
All Rights Reserved. IBM, the IBM logo, and Tivoli are trademarks
of IBM Corporation in the United States, other countries or both.
The “sweet spot” seeemes to be 4096 for MaxTFTPSegSize, any higher the load would hang.
Harald
Good sleuthing! I guess the rembo.conf may not contain MaxTftpSegSize if it’s at the default value.
As far as the sweet spot for the value, it depends somewhat on the boot rom of the pxe client. I had problems with VMWare clients going above some value…maybe 2048 seg size or 8 blocks maybe?
Anyway depending on network hops 1432 should be “ideal” in terms of preventing the UDP packet from getting fragmented (based on an Ethernet MTU of 1500 bytes) while a larger number of blocks per segment helps with the round-trip delay to the client.
